On the Security of RC4 in TLS and WPA – Full Paper Released

http://www.isg.rhul.ac.uk/tls/?new

by tptacek • 13 years ago

65 25 13 years ago

isg.rhul.ac.uk

tptacek6• 13 years ago

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 dened 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 fixed 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.

jgrahamc3• 13 years ago

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• 13 years ago

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).

tptacek6• 13 years ago

I dispute the first graf for three reasons. First, the attack (you can play with it yourself; it's one of our upcoming crypto challenges) is relative to the start of the art in cryptography devastatingly easy to carry out; it takes a large amount of time, and may not be suitable for mass attacks, but one can imagine circumstances today in which this attack could be workable for targeted high-value secrets. Second, the kinds of advances in this attack that will make it more viable are less likely to be cryptographic and more likely to be systems programming related; as people play with the attack and explore more of the interactions between browsers and (say) specific RC4 bias positions, I think we're likely to find "non-cryptographic" (to coin a term) refinements of the attack that will make it scarier. The tempo of these kinds of advances is much, much faster than the tempo of fundamental advances in crypto. Finally, I think that graf doesn't adequately capture the other circumstances in which RC4 is used --- it's not a hair-on-fire operational issue for the web today, but it might be hair-on-fire for less well-understood cryptosystems.

mindslight• 13 years ago

The sentence immediately preceding what you quoted is necessary for understanding:

Suppose byte Zr of the RC4 keystream has a dominant bias towards value 0x00.

tptacek6• 13 years ago

It's necessary to understand why the attack works, but not so much for understanding how to implement it. But you're right.

peterwwillis• 13 years ago

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!

jgrahamc3• 13 years ago

To be honest the writing has been on the wall for RC4 for a while and there are viable alternatives. People should have at least been prioritizing other TLS suites before this news.

zentrus• 13 years ago

Have you read other articles relating to TLS security over the last several months? Keeping in mind BEAST and Lucky 13 and browser support, I would ask you which ones you would prioritize over RC4 and why?

agwa• 13 years ago

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.

marshray2• 13 years ago

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? :-)

yuhong• 13 years ago

I think Win8.1 preview SChannel already have RC4 disabled by default.

mikegioia2• 13 years ago

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.

tptacek6• 13 years ago

Because here "client-side bot" includes bots written in Javascript served up from arbitrary pages on the web.

I don't understand your second question, like, at all.

mikegioia2• 13 years ago

I'm asking why configure your web server to use RC4 at all if there are better algorithms to use. I'm under the assumption that people use RC4 because it's either less taxing on the web server, or more browsers support it.

JshWright3• 13 years ago

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...

StavrosK2• 13 years ago

I'm the web guy for Silent Circle.

cough

On the Security of RC4 in TLS and WPA – Full Paper Released

Related Stories