

On the Security of RC4 in TLS and WPA – Full Paper Released - tptacek
http://www.isg.rhul.ac.uk/tls/?new

======
tptacek
Click the sidebar for a link to the full paper. I'm fond of feigning disbelief
at how simple this attack is, given how widespread RC4's adoption is. Of the
crypto attacks you'll read about, this is among the simplest to understand.

    
    
        As RC4 encryption is dened as Cr = Pr ^ Zr, the corresponding ciphertext byte Cr 
        has a bias towards plaintext byte Pr. Thus, obtaining sufficiently many ciphertext 
        samples Cr for a fixed plaintext Pr allows inference of Pr by a majority vote: Pr 
        is equal to the value of Cr that occurs most often.
    

(This attack turns out not to be directly workable, but the working attack
isn't much harder.)

This is operationally important crypto research; if you understand it, you may
configure your servers differently.

~~~
jgrahamc
I think these two paragraphs are critical for the lay reader:

"This said, it would be incorrect to describe the attacks as being a practical
threat to TLS and WPA today. However, our attacks are open to further
enhancement, using, for example, the ability of our algorithms to output
likelihoods for candidate plaintext bytes coupled with more sophisticated
plaintext models."

"We recognise that, with around 50% of TLS traffic currently using RC4,
recommending that it be avoided completely in TLS is not a suggestion to be
made lightly. Nevertheless, given the rather small security margin provided by
RC4 against our attacks, our recommendation is that RC4 should henceforth be
avoided in TLS, and deprecated as soon as possible."

~~~
trebor
So, given that virtually every HTTP request has a uniform header, you'd need
an adequate number of requests to the same page. That sounds impractical, but
it won't stay that way for long. 2^24 is only 16.77 million requests,
something not-so-difficult to achieve by a botnet, especially on sites that
scale well (slower sites would be safer, actually).

~~~
jnbiche
Is it possible that at least some of the high-profile "DDOS" attacks on Mt.Gox
that took place earlier this year[0] were actually attempted RC4 attacks?
There would have been a payoff worth the effort. I checked, and indeed Mt. Gox
was using (and still uses) RC4[1]:

0\.
[https://mtgox.com/press_release_20130404.html](https://mtgox.com/press_release_20130404.html)

1\. [http://security.stackexchange.com/questions/18863/how-
secure...](http://security.stackexchange.com/questions/18863/how-secure-is-
https-with-weak-ciphersuites)

------
mikegioia
This is pretty interesting.

    
    
        The attacks can only be carried out by a determined
        attacker who can generate sufficient sessions for the
        attacks.
    

2^30 connections seems pretty insane to me. Who the hell can generate that
many without having a client-side bot running, and if a client-side bot is
running who the hell cares about RC4?...

Also, is it really such a big deal to use AES-256 or AES-GCM now? I mean, (a)
we're not running web-servers on 1998 hardware and (b) we're not designing
sites for IE6 and under any more.

~~~
JshWright
I'm not sure what you mean by 'AES-256 _or_ AES-GCM' (since you can use 128 or
256 bit key sizes in either CBC or GCM mode), but the problem with GCM mode in
general is that no clients support it...

I'm the web guy for Silent Circle. We run in-house analytics on our
'marketing' sites (we don't run any analytics (or even log remote IP addresses
or user agents) on any site that a user can authenticate (and therefore
identify themselves) to)(I'm not a Lisper... honest...). We recently upgraded
the server that hosts the analytics to a sufficiently recent version of
OpenSSL that it now supports TLS 1.1+ and GCM mode ciphers.

I was curious how many connections actually used GCM ciphers, so I started
logging the TLS version and cipher suite for each connection. I only did this
a couple days ago, so I don't have a ton of data yet, but the short answer
is... Almost no one supports GCM. GCM ciphers are highest priority in our
cipher list (and server ciphers are preferred), and yet I've seen almost no
GCM connections. Far and away the most common cipher suite is ECDHE-RSA-
AES256-SHA (~75% of connections).

Note: This is for our marketing sites, not the site our customers actually
authenticate to, so the results might differ a bit when it comes to our actual
customers...

~~~
StavrosK
> I'm the web guy for Silent Circle.

 _cough_

~~~
JshWright
...and StavrosK is the web lackey ;) (Who gets to do most of the fun stuff
lately...)

~~~
StavrosK
I'm going to commit a piece of code that doesn't conform to PEP8 and make it
look like you did it.

------
peterwwillis
I feel bad for the sysops who're scheduling 3am maintenance windows on
production TLS services for the edge case this presents. God damn security
researchers!

~~~
agwa
Except that's not going to happen because for now the only viable alternative
to RC4 in TLS is AES in CBC mode, which suffers from its own problems (BEAST
and Lucky 13). It's really a question of which is worse, and that's not so
easily answered.

~~~
marshray
The RC4 attacks currently require the client being attacked to make millions
of connections to the legitimate server. However, this could be done over a
long period of time and the webserver may not even log an error for each
attempt.

Under the right circumstances, BEAST can be exploited with a real-time
practical number of connections. It was demoed on stage. Those circumstances
don't include every browser configuration, but they're not very extraordinary.

Does that answer your question? :-)

~~~
tptacek
The circumstances BEAST relies on involves a rapidly diminishing set of
browsers. As I understand it, BEAST is less of a motivator for RC4 than Lucky
13.

~~~
marshray
Never thought I'd see the day when browsers are patched (against BEAST) faster
than servers (Lucky 13).

