« SSL Labs: Announcing launch of two Convergence notaries | Main | TLS Renegotiation and Denial of Service Attacks »

Mitigating the BEAST attack on TLS

October 17, 2011

Update (19 March 2013): This blog post advises to use RC4 to migitate the BEAST attack, but RC4 has recently been discovered to be weaker than previously known. At this point the attacks against RC4 are still not practical. The only fully safe choice at the moment is the AES-GCM suites supported only in TLS 1.2. You can find out more in this new blog post.


During the summer rumours about a new attack against SSL started circulating. Then Opera released a patch, but made no comment about what it was patching. Eventually enough information leaked out that some smart people figured what the attack was about. What remained unknown was the exact technique used in the proof of concept, and that was eventually explained in Thai's blog post. For a comprehensive overview of related links, go to Thierry Zoller's blog post on BEAST.

As it turns out, the attack itself was conceived years ago, deemed impractical, but it was nevertheless fixed in TLS 1.1. The new attack technique introduced a few optimizations to make it practical.

In terms of mitigation, I expect this problem will be largely addressed on the client side, despite a potential compatibility problem that may cause some TLS sites to stop working. The only reliable way to defend against BEAST is to prioritise RC4 cipher suites, as proposed by PhoneFactor.

Just as an example, here's one way to do the above in Apache:

SSLHonorCipherOrder On
SSLCipherSuite RC4-SHA:HIGH:!ADH

Not everyone likes RC4, even though there is little to no evidence that it is insecure in the context of SSL/TLS. If your server supports TLS 1.2+ you can try the approach recommended by Steve Caligo:

SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH

The idea is that you put a few TLS 1.2 cipher suites first so that they can be picked up by TLS 1.2 clients, which are not vulnerable, followed by RC4 for TLS 1.0 clients.

Now that I've discussed what works as mitigation, let's look at a few approaches that do not work:

  • Supporting TLS 1.1+ server-side is a good start, but does not amount to much because very few clients support newer versions of the protocol at this time. And even with TLS 1.1+ support client-side, there's nothing preventing the MITM to force a protocol downgrade back to TLS 1.0. (For a discussion on defense techniques against downgrade attacks, see this thread on the TLS WG mailing list).
  • Enabling the empty fragment technique server-side (details for OpenSSL here) does not work either. TLS 1.0 uses two initialisation vectors (IVs), one each for client- and server-side of the communication channel. The vulnerability exploited by BEAST is on the client-side and cannot be addressed by making server-side changes to how data is sent.
  • Compression is said to make the attack impossible, but, as with TLS 1.1+, the support for it client-side is inconsistent.

Update (20 Jan 2012): In testing OpenSSL 1.0.1-beta2, which came out yesterday, I realised that it will happily negotiate AES-CBC-SHA256 even on a TLSv1.0 connection. So I removed it from the recommendation, replacing it with two other TLSv1.2 cipher suites.

MY BOOK: If you like this blog post, you will love Bulletproof TLS and PKI. For system administrators, developers, and IT security professionals, this book provides a comprehensive coverage of the ever-changing field of SSL/TLS and Internet PKI and will teach you everything you need to know to protect your systems from eavesdropping and impersonation attacks. It's available now.