First The BEAST Threatened Us, But Now We Have Worse Things To Worry About

In Learning Tree’s Cloud Security Essentials course we have been discussing the BEAST attack. I wrote about it here last spring.

Things have shifted recently, it’s time to update the discussion.

TLS 1.0 and earlier SSL versions had a serious flaw that allowed an attacker to recover small fragments of cleartext, exposing authentication credentials. The fairly ridiculous situation was a fix had been available since 2006, but as of September, 2011, 99.7% of the most popular HTTPS servers on the Internet did not support it. The web server developers blamed this on the lack of browser support for TLS 1.1 and later, while the browser developers blamed this on the lack of server support.

The recommendation at the time was to enforce the use of the RC4 stream cipher only on the server side, because BEAST attacked a specific mode of block cipher use.

Since that time, most browsers have fixed BEAST’s purely client-side vulnerability. Apple didn’t. OS X is a closed system, so the details aren’t available, but it seems that the fix was included but disabled in the Mountain Lion release of OS X, nor is it used in iOS.

The excellent and useful Qualys SSL Labs SSL Server Test strongly favoring those servers that applied a server-side BEAST workaround by enforcing the use of RC4 in place of other ciphers. By the spring of this year, about 50% of all TLS traffic was encrypted with the RC4 cipher. But just a a week ago, on September 10, that changed. Qualys now penalizes servers that support RC4.


RC4 is weaker than we thought. You can look at the research papers or a more easily readable summary, but RC4 is significantly weaker than we thought. It’s been around since 1987, and the weaknesses have finally been discovered.

Some of the RC4 problems along the way have been caused by its misuse, as was the case with WEP. But the new work shows that the problems extend to the RC4 key scheduling algorithm and to the non-randomness of its pseudo-random key stream. That is, the key stream is deterministic, the same key always generates the same bit stream to be XORed with the data, but that bit stream should be indistinguishable from a truly random bit stream. But meanwhile researchers keep finding patterns leaking through in the RC4 output.

What to do?

It’s up to the developers of the servers and browsers. There are some further RC4 workarounds to be applied. But it looks like the best fix be be a move to a good block cipher like AES used in Galois/Counter Mode or AES-GCM. This is part of the TLS v1.2 specification.

Qualys has decided that since the RC4 weaknesses are serious and effect everyone, while Apple’s apparent reluctance to do client-side BEAST workarounds effects only Apple users, the least bad solution is to penalize RC4 use.

We need TLS v1.2 on both the client and server side across all platforms. But unfortunately, this seems unlikely to happen any time soon.

Bob Cromwell

Type to search

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.