

RC4 in TLS is broken: now what? - gmac
https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what

======
tptacek
This article's opening line:

 _RC4 has long been considered problematic, but until very recently there was
no known way to exploit the weaknesses._

... is especially amusing once you learn how to exploit the flaw in RC4 he's
talking about. It's among the simplest, most blatant crypto algorithm flaws
ever published. It's also very old; it was known at approximately the same
time as RC4's first publication on the Internet.

~~~
sdevlin
> once you learn how to exploit the flaw in RC4 he's talking about

Quick version: RC4 has biases in the key stream it generates. This means that
for a given offset, certain bytes are more likely to appear than others. How
do you exploit this? Collect a large sample of the same plaintext encrypted
under different key streams. Examine the biases apparent in your samples and
compare them to the actual key stream biases. You should be able to infer the
actual plaintext byte.

------
jrochkind1
_At the moment, the attack is not yet practical because it requires access to
millions and possibly billions of copies of the same data encrypted using
different keys. A browser would have to make that many connections to a server
to give the attacker enough data. A possible exploitation path is to somehow
instrument the browser to make a large number of connections, while a man in
the middle is observing and recording the traffic._

Does it need to be a single browser? If you have recorded a substantial
portion of internet traffic (as the NSA has), and thus you have connections
from a bunch of different browsers to a popular SSL/https web page, and the
server (during a given time period) returns the exact same response (it's
static web page) to all of them (or a portion of them and you can figure out
which portion)....

?

I can think of a bunch of different reasons this would NOT work, but (or
'and') I'm also not neccesarily an expert and don't entirely understand this
stuff, so I'm not sure either way, just wondering.

~~~
Skalman
But... aren't headers also encrypted? Won't the "Date: Thu, 27 Jun 2013
14:20:43 GMT" header make it unlikely that there will be more than x000 copies
of the exact same data encrypted?

~~~
sdevlin
RC4 is a stream cipher. This means you have a stream of key bytes and a stream
of plaintext bytes. You pair these up and XOR each pair together to get a
stream of ciphertext bytes.

The key stream is generated independently of the plaintext, so the attacker
really only cares that the bytes he's interested in (i.e. session cookies)
stay at the same offset in the stream.

------
Nursie
Don't use it and switch to AES_GCM?

OK I guessed right...

~~~
hga
When I looked into this a while ago, including this late March article, the
problem was that you still have to accept RC4 because it's the least worst for
too many modern enough browsers. E.g. this is what I'm using right now:

ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!aNULL:!ADH:!EDH:!MD5:!3DES

~~~
Nursie
Ah yeah, I'm not a web guy so I didn't think much about browsers. I guess that
does make life more difficult.

