I had assumed that TLS didn't use plain RC4, but rather a variant of RC4 that discards the first several hundred bytes of the keystream to avoid this problem. But I just checked and apparently TLS uses straight-up RC4. Sigh...
I'm not sure why people so fervently recommend disabling AES-CBC (and SSLLabs knocks you a whole letter grade if you haven't) when modern browsers and TLS clients work around BEAST with "1/n-1" record splitting [1]. I figure out-of-date browsers are probably vulnerable to something that lets you hijack sessions without needing BEAST anyways.
Not all major browsers implement 1/n-1 record splitting. In particular, the last time I checked, Apple did not in Safari and the iOS devices. In that light, downgrading the grade to a B is a reasonable way to indicate that your configuration is not secure for a potentially large portion of the user base.
The 1/n-1 split is the main reason that the grade is just reduced and sites are not simply failed (as is the case with insecure renegotiation, for example). The other reason is that the BEAST attack is not exactly easy to execute.
Knowing what we know today, attacks against RC4 are not yet practical, and thus there is no reason to panic. But we must act now. Given the huge incentive for researchers to continue to break RC4, it's reasonable to expect that the attacks will continue to improve.
Yes, SSL Labs will start to penalize RC4 at some point, but not just yet. Later today we will start warning people about the problems.
First, the record split problems caused compat issues.
Second, even with the record splitting fix, you still have Lucky 13, which is really annoying to fix completely, and people are wary of deploying a crypto fix to their SSL library that in 5 years we'll just find out was window dressing.
CBC at the moment I think. There's still the possibility of clients without record splitting, there's timing issues in AES itself, there's lots of possibilities for bad server padding implementations.
I have TLS 1.2 and AES-GCM working in NSS on my desktop, but we don't currently have the NSS reviewer time to get it landed. We also have to deal with the issue that an active attacker can trigger a version downgrade somehow. (I don't love AES-GCM either, but it's the nearest port in this storm.)
In the mean time, I'll probably tweak RC4 in NSS to send one byte records at the beginning of the connection and thus burn off the first 256 bytes of keystream by encrypting MACs. That still leaves a handful of bytes vulnerable, but half of them will be "GET ".
But I doubt that's fully sufficient so AES-GCM is the medium term goal.
Is this what web security is reduced to? On one hand, openssl not releasing TLS 1.2 support for over 3 years until a semi-panic over BEAST generated enough interest to get it done? On the other, major browser vendors not implementing TLS 1.2 (okay, MS did, but disabled by default) for even longer because lack of server support, compatibility issues, or fear of protocol downgrade attacks made it an uninteresting or risky proposition? Nobody was interested enough to say screw chicken-and-egg and simply get it done, on either side?
OS maintainers aren't helping either. RHEL/CentOS 6.4, just released, is still stuck with openssl 1.0.0, which doesn't support TLS 1.1 or 1.2, so there's another few years of webservers running an "enterprise" OS not having TLS 1.2 support. But hey, OpenSSL 1.0.0 is "stable"!
I guess there's not much hope of getting Salsa20 or ChaCha, and better curves like curve25519 (I see a draft proposing some Brainpool curves), into TLS 1.2? (with the intent of discouraging many of the less desirable ciphersuites after a few years... not adding more ciphersuites just to add more ciphersuites.)
If some catastrophic problem is discovered where there's a practical attack on block ciphers as used in the TLS ciphersuites, with no clever spec-compatible mitigation techniques, it would be nice to have a stream cipher in TLS (and implemented in the major TLS libraries) that isn't known to be problematic like RC4 is.
How long would it take to fix TLS implementations for high security applications in that scenario? And what would be the probable response? I think Salsa20 has a good chance of being the "fix"; maybe it wouldn't have to go through a truncated RFC process, and the major stakeholders would simply agree to add it to their TLS implementations and ship, but even then it would take significant time to implement and review.
You and others complain about the hodgepodge of ciphersuites in TLS.[1] South Korea gets their obscure block cipher into TLS, and yet the only stream cipher currently in TLS is known to be flawed and hasn't been ripped out and replaced?
Curve25519 was an afterthought before I looked and noticed 3 brainpool curves seem to be on track for inclusion, but Curve25519's parameters are more cautiously selected than the curves already in TLS implementations (secp256r1 for instance being the closest equivalent, and a common default curve for ECDH).
[1] I can see that the design-TLS-by-committee strategy doesn't seem to be working optimally. Someone credible ought to step up and demand a return to sanity. TLS 1.2 is barely even supported yet in practice, and yet there are 32 AES TLS 1.2 ciphersuites (by openssl 1.0.1e's count, and more that it hasn't implemented), 16 of which are RSA-based?! To take one example, TLS 1.2 RSA ciphersuites that use plain DH... what are they for? The parameters in TLS-enabled applications are traditionally hardcoded for 1024 bit DH, which decreases the security of sites using 2048+ bit rsa keys... and who uses 2048+ bit DH in practice? It's slow, and ECDH is the obvious choice. Then there are lots of less popular ciphersuites (most not even supported by openssl or nss), and as far as I can tell, that's driven by software and hardware companies who want a particular ciphersuite for their commercial products and want it in the official TLS spec, even though that does no good because major TLS libraries will not support obscure ciphersuites.
But more seriously, salsa is very efficient, so if rc4 is still being used for performance reasons, rather than security reasons, then it would seem to be to be a decent replacement.
Whoah, neat. I didn't realize the RC4 workaround was that straightforward. Easy to forget you still have the record layer when you're using a stream cipher. Thanks, this was an excellent comment.
So what exactly are the NSS reviewers doing instead? Also, could you reorder HTTP headers to put cookies last? And at what point do we say "Screw it, TLS is dead"?
Apparently the compat issues with record splitting have been resolved sufficiently well that all the major browsers have turned it on.
Yeah, there's Lucky 13 but you said above that this RC4 vulnerability is unacceptable in a way that Lucky 13 isn't. Basically I'm wondering what the point is in fervently recommending RC4 over AES-CBC when they both suck.
I'm not sure why people so fervently recommend disabling AES-CBC (and SSLLabs knocks you a whole letter grade if you haven't) when modern browsers and TLS clients work around BEAST with "1/n-1" record splitting [1]. I figure out-of-date browsers are probably vulnerable to something that lets you hijack sessions without needing BEAST anyways.
[1] http://www.imperialviolet.org/2012/01/15/beastfollowup.html