On the Security of RC4 in TLS and WPA – Full Paper Released | Hacker News Reader

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

isg.rhul.ac.uk

65 pointstptacek25 comments

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.

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

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

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

1. http://security.stackexchange.com/questions/18863/how-secure...

The goal with this attack is to listen in on (and have some degree of control of the plaintext contained in) requests between the server and a specific client. A botnet wouldn't help you do that.

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.

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.

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

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.

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.

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.

Oh, sorry. A few years ago, people might have selected RC4 for its speed. These days, people who deliberately enable RC4 are doing it because they're concerned about the Lucky13 attack on TLS CBC. It's a rock/hard-place situation with a pair of TLS vulnerabilities that both require adoption of TLS 1.2 to decisively mitigate.

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

> I'm the web guy for Silent Circle.

cough

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

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

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!

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.

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?

I am well aware of these attacks as I am actively involved in discussions at CloudFlare about how we best protect our customers. Clearly browser support for things like AES GCM and TLS 1.2 is the limiting factor.

However, TLS is not only used between browser and web server. We can use better ciphers in situations where both ends can be controlled.

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.

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

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.

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

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

Reply on news.ycombinator.com