Tag Info

Hot answers tagged

24

First things first: don't panic. Don't do anything rash, and take time to think. The slides which have appeared today describe new results on bias in RC4. RC4 generates a key-dependent stream of pseudo-random bytes, which is then XORed with the data to encrypt (decryption is identical). It was known that the output of RC4 was slightly biased, i.e. some byte ...


16

After several hours trying to figure out how to do that in Google Chrome I've found it! You must add the following command line parameters in the shortcut: --cipher-suite-blacklist=0x0005,0x0004 The tricky part is that Google has not translated cipher strings so you must input each cipher in hex based on RFC 2246: 0x0004 = TLS_RSA_WITH_RC4_128_MD5 ...


8

The traditional RSA-based exchange in SSL is nice in that a random session key is generated and transmitted using asymmetric encryption, so only the owner of the private key can read it. This means that the conversation cannot be decrypted by anyone unless they have the certificate's private key. But if a third party saves the encrypted traffic and ...


7

Google Chrome Version 28.0.1500.95 chrome.exe --cipher-suite-blacklist=0xc007,0xc011,0x0066,0xc00c,0xc002,0x0005,0x0004 0xc007 = ECDHE-ECDSA-RC4128-SHA 0xc011 = ECDHE-RSA-RC4128-SHA 0x0066 = DHE_DSS_WITH_RC4_128_SHA 0xc00c = ECDH_RSA_WITH_RC4_128_SHA 0xc002 = RSA-RC4128-SHA 0x0005 = RSA-RC4128-SHA 0x0004 = RSA-RC4128-MD5 Source list of cipher names ...


6

RC4 has known biases, which have been measured with great accuracy. Exploiting these biases into an actual attack requires observation of many (millions) of successive connections where some specific secret data (say, a given password) always appears at the same place. Such a scenario can be forced in lab conditions but barely applies to practical, real-life ...


6

BEAST is a client-side attack, so all you can do on the server side is to avoid letting unaware clients put themselves in a BEAST-vulnerable position. However, modern clients (Web browsers) are not vulnerable to BEAST anyway: Clients use record splitting (usually 1/n-1) as a countermeasure. BEAST requires the hostile in-browser code (in Java or Javascript) ...


6

As @D.W. points out, this would work -- to protect the cookie. The path itself comes before the headers, and may also be at risk, if it contains sensitive data at a predictable place (this is not a common case nowadays, but URL rewriting for session management used to be popular). A variant would look like this: GET / HTTP/1.1 X-Header-Padding1: <X ...


5

In a "DHE" cipher suite, the server generates on-the-fly a new Diffie-Hellman key pair, signs the public key with its RSA or DSA or ECDSA private key, and sends that to the client. The DH key is "ephemeral", meaning that the server never stores it on its disk; it keeps it in RAM for the duration of the SSL handshake, then forgets it altogether. Being never ...


4

This would be safe against all attacks that I know of. From a security perspective, it is not quite equivalent to dropping the first 256 or 512 bytes. With your proposal, the attacker has some known plaintext (e.g., from the GET line and the X-Padding-Header), whereas if you drop the first 256 bytes, the attacker doesn't get known plaintext in those ...


4

The biggest reason I can think of as to why they might want to use RC4 is because of compatibility with Jira (and or this custom auth backend that we cannot vet.) AES128 support was introduced along with Server 2008 and Vista, and AES256 with 2008 R2 and Win7. However, the KDC will automatically negotiate down to (for instance) RC4 when talking to, say, a ...


4

Yes. The protocol itself is no longer secure, as cracking the initial MS-CHAPv2 authentication can be reduced to the difficulty of cracking a single DES 56-bit key, which with current computers can be brute-forced in a very short time. The attacker can do a MITM to capture the handshake (and any PPTP traffic after that), do an offline crack of the handshake ...


4

If you connect to this site with your Web browser, it will show you what protocol versions and cipher suites are supported by that browser. Notably, Firefox does not seem to support (yet) TLS 1.1 and 1.2, so this prevents it from using any cipher suite ending in "_SHA256" because these are for TLS-1.2 only. If your server is accessible from the Internet, ...


4

What you call the "XOR attack" is based upon the secret stream being reused; i.e. there is some secret stream S, data D that gets encrypted by XORing it with S, and some other data D' that gets encrypted by XORing it with the same secret stream S. In that case, if the attacker knows D he learns D'. However, when RC4 is used in SSL, the key is brand new for ...


3

TL;DR You need to use the following parameter to block all RC4 ciphers (as of Chrome 31 in Ubuntu 12.04 with NSS 3.15) --cipher-suite-blacklist=0x0004,0x0005,0xc011,0xc007 In Google Chrome on Ubuntu you have to edit the file /usr/share/applications/google-chrome.desktop and add the parameter to each line that starts with ...


3

Banks are usually not known to work in an agile way and quickly follow the latest developments. Like with lots of other large companies there is lots of paper work involved if somebody tries to change something, which costs efforts, man power, time and thus money. I don't think that a system administrator just can decide to change the ciphers. Instead it ...


3

I guess the most concise answer to this question is: They are insured. Currently industry standards don't require PFS and therefore insurances pay even if the bank had no PFS. There was a similar question on 30c3, about why the banks are using Windows XP as their operating system. Those standards can also be a reason why banks can't implement new methods ...


3

There are known biases in RC4 output, especially in the first bytes of the stream. In the "Gmail scenario", the client (Web browser) regularly connects to the server to poll for new incoming messages. Each connection implies encrypting the request data with a fresh RC4 stream; and all the requests will contain the same secret value at the same place in the ...


3

In any case, the client suggests but the server chooses. On the client side, you can specify that you prefer to use AES if possible, but if the client supports RC4 and the server wants to use RC4 if possible, then RC4 it will be. This implies that you cannot really "use RC4 as a last resort" (unless the client code does some trickery, which I don't believe ...


3

BEAST vulnerability has been worked out client-side, so it's no longer an issue with modern browsers. RC4 is a weaker cipher than others since it's been shown to have a slight bias, but if used carefully and appropriately, there are no successful attacks against it. You can't get any safer than safe; if your encryption can't be broken, then it doesn't ...


3

If I understand this issue tracking thread, support for disabling some cipher suites in SSL/TLS has been at least partially implemented, but there is no corresponding user interface. It seems to be feasible through command-line arguments (I have not tried). Also, the exact method may change depending on the operating system, since Chrome tends to reuse the ...


3

Cryptographically "broken" and just plain "broken" are different things, the former is usually taken to mean "less than brute force" (which can still be improbably expensive to achieve). Aside from the fact that two ciphers, AES and RC4, are different internally (CBC block cipher, and stream cipher respectively), the observable differences are that AES-256 ...


2

You (or they, the ones who propose the change) do not give a reason for switching to RC4, do you? RC4 is a stream cipher, which is vulnerable in some particular cases: RC4 has weaknesses that argue against its use in new systems. It is especially vulnerable when the beginning of the output keystream is not discarded, or when nonrandom or related keys ...


1

It is possible to encrypt a pdf with AES: https://blogs.adobe.com/security/2011/08/pdf-encryption-options.html I thought that the structure tree was encrypted (ie. that it was a stub pointing to a big blob containing the rest of the content). But I haven't reviewed it, you seem to have a greater knowledge of that. In order to confirm that the document is ...


1

A lot of the people recommending RC4 to prevent BEAST have recanted because of the attacks on it; the correct and forward-looking solution is updating your software to the TLS 1.1 spec. Strategically, your options depend on your abilities. If you are allowed to dictate the user agents connecting to your service, or willing to accept that your user agent ...


1

Unless you need to be FIPS compliant I wouldn't disable rc4 md5. You can simply prefer it as a last resort. You can configure your webservers in such a way that they will only resort to rc4md5 if the client does not support any other ciphers you offer. This way you needn't worry about supporting legacy clients. To my knowledge older phones sometimes only ...



Only top voted, non community-wiki answers of a minimum length are eligible