Attackers can use Javascript and/or browser plugins to coerce browsers into making millions of requests to (say) GMail, specifying the URL to make the session cookie line up at a specific point in the plaintext. Similar techniques animated BEAST, CRIME, and Lucky 13.
Now, for sites that use RC4 (to mitigate BEAST and Lucky 13), attackers can take advantage of a flaw in RC4: RC4's keystream output has biases throughout the first 256 bytes. Over millions of trials, these biases make it possible to use basic statistics to predict cookies, from the vantage point of a passive attacker.
This is one of the easier-to-understand TLS flaws of the last few years. RC4 is simple: you key it and it spools out a Hard-to-predict stream of random bytes, which are XOR'd to the plaintext. If those bytes aren't Hard to predict in some way, the attack is obvious. Now that (a) we know how to get browsers to generate millions of sessions (hello, BEAST) and (b) half the Internet is now using RC4 (thanks, BEAST), these RC4 attacks have become germane.
My guess is that these attacks are (1) noisy, (2) slow, (3) unreliable, and (4) expensive --- not in a "need a grid of PS3s to exploit" kind of way, but in a "nobody will cast a broad net across the Internet with this attack" sort of way.
But the vulnerability is also plainly unacceptable, in a way that I don't think is true of "Lucky 13" (which isn't intractable to fix in application code, just very annoying to fix).
It looks like we're finally reaching a place where TLS compat is going to stop dictating what attacks we mitigate and how, because unless we opt to accept the risk of poor "Lucky 13" fixes, there's no compatible way out. We need a widely deployed authenticated ciphersuite.
> unless we opt to accept the risk of poor "Lucky 13" fixes, there's no compatible way out.
What particular class of fixes are you referring to by 'poor "Lucky 13" fixes'? Do you mean that getting Google, Yahoo, Facebook, Amazon, Microsoft, and Mozilla Foundation all to stop using a particular cipher is unworkable, or that TLS is just too broken and needs to be replaced, or both?
When one is in a game of whack-a-mole, something is probably broken somewhere. It seems like your position comes down to this:
We programmers mostly know that ciphers are hard to design and should only be designed by experts.
We programmers mostly know that designing a protocol is also hard and should only be designed by experts. In fact, it turns out they're even harder than ciphers to get right.
What our community still isn't getting and dealing with correctly, is that implementing ciphers, protocols, and security software with current techniques is hard and should only be done by experts.
It all smacks of the kind of problem newb programmers have if they haven't studied concurrency and they decide to build their first concurrent system. This makes me wonder if better tools could be made on the language level, like a functional language and formal system designed to enable provably secure systems, also accounting for timing attacks. Such languages would probably have to leave out embedded systems, but might stand a reasonable chance of covering desktop, mobile, and browser applications.
Now, for sites that use RC4 (to mitigate BEAST and Lucky 13), attackers can take advantage of a flaw in RC4: RC4's keystream output has biases throughout the first 256 bytes. Over millions of trials, these biases make it possible to use basic statistics to predict cookies, from the vantage point of a passive attacker.
This is one of the easier-to-understand TLS flaws of the last few years. RC4 is simple: you key it and it spools out a Hard-to-predict stream of random bytes, which are XOR'd to the plaintext. If those bytes aren't Hard to predict in some way, the attack is obvious. Now that (a) we know how to get browsers to generate millions of sessions (hello, BEAST) and (b) half the Internet is now using RC4 (thanks, BEAST), these RC4 attacks have become germane.
My guess is that these attacks are (1) noisy, (2) slow, (3) unreliable, and (4) expensive --- not in a "need a grid of PS3s to exploit" kind of way, but in a "nobody will cast a broad net across the Internet with this attack" sort of way.
But the vulnerability is also plainly unacceptable, in a way that I don't think is true of "Lucky 13" (which isn't intractable to fix in application code, just very annoying to fix).
It looks like we're finally reaching a place where TLS compat is going to stop dictating what attacks we mitigate and how, because unless we opt to accept the risk of poor "Lucky 13" fixes, there's no compatible way out. We need a widely deployed authenticated ciphersuite.