Which TLS algorithm should I use?

TLS is a vital to the internet, but there have been some TLS protocol level attacks lately. I spent a lot of time investigating all these attacks to find out what F5 should do. After the recent rash of attacks, I thought there was a lot of confusion and not a lot of easily accessible information available to the average system administrator who just wants to make sure his application and his customers were safe. This post will describe the attacks and help you to sort them out and make a recommendation for BIG-IP users. The attack descriptions have been simplified quite a bit, reference links are included if you would like to dig deeper.

Ciphers in TLS

In 2001 the AES standard was established by the US NIST to replace the aging 56 bit DES algorithm. AES has fared very well over the years. It's a block cipher with 128, 192 and 256 bit block sizes. Even 128 bits is still considered strong enough for most uses; the latest attack from 2011 still requires 2^126.1 operations, which is close enough to brute force.

But there's been a rash of attacks against the TLS protocol lately that have left many people wondering what cipher they should use.

It's not that AES itself is a problem, it's that the specific mechanism of cipher block chaining (CBC) used by the TLS protocol has been weakened in a few different ways. CBC feeds each cipher block back onto the next block and ensures that similar blocks of plaintext are not encrypted into the same cipher text. There's a great article on Wikipedia of electronic code book (ECB) vs other encryption modes that includes a description of cipher block chaining.

Side note: Most of these attacks attempt to retrieve an application authentication cookie. These attacks do not retrieve your RSA secret key nor do they obtain the TLS session key, those are still kept secret.

Once an attacker has a user's authentication cookie, he can impersonate that user until the cookie expires. Your application authentication cookie should have the HTTPOnly and Secure attributes set so that an attacker can't easily obtain it. If your app doesn't have those attributes set on your auth cookie, the BIG-IP can easily add them. The below attacks all assume these are set and the attacker can’t get the cookies easily.

BEAST Attack

F5 Projected Threat Level - Low

The BEAST attack from Thai Duong and Juliano Rizzo from 2011 demonstrated a previously known flaw in TLS that allows a chosen plaintext attack. An attacker who can capture your network traffic and get code into your browser (called a man in the browser or MITB) could force your browser to repeatedly encrypt the same information along with some chosen plaintext. The BEAST researchers showed that the attacker is able to recover secret information through careful analysis of the encrypted messages. Fortunately, it only affects TLS1.0 and the latest browsers have implemented a record splitting workaround. Even though the server isn’t involved, the server side solution is to move up to TLS1.1 or 1.2 because these newer versions of the protocol initialize the cipher differently.

F5 thinks this has a relatively low threat potential because of the complexity of the attack and because modern browsers now have workarounds. Users with old browser may still be vulnerable though.

References: Thai Duong's blog post, Tor project's analysis.

CRIME Attack

F5 Projected Threat Level - Low

The CRIME attack from 2012 was a similar attack from the same authors that also allows an attacker to decrypt plaintext. In this attack, the MITB sends many requests with small changes that are compressed before being encrypted. The attacker watches the traffic and derives information about the plaintext from the size of the compressed blocks. The solution is to disable TLS compression (note this is not HTTP content compression). If your client or server does not support TLS compression then this attack is not feasible. Most recent browsers have already disabled TLS compression.

BIG-IP does not currently support TLS1.x compression although HTTP compression is supported.

F5 thinks this has a relatively low threat potential because of the complexity of the attack and because BIG-IP does not support TLS compression.

References: ARS article.

Lucky 13 Attack

F5 Projected Threat Level - Low

The Lucky 13 attack (AlFardan and Patterson) from February 2013 includes a MITB, but also has an active listener who modifies the browser ciphertext and waits for the response from the server. By timing the response, the attacker learns which ciphertext blocks have correct padding. The attacker uses this information leak to eventually recover the plaintext of the message.

I know of no server side workaround except to disable CBC mode. A BIG-IP uses hardware for TLS offload and we believe significantly less vulnerable to timing attacks.

F5 thinks this has a relatively low threat potential because of the complexity of the attack and because of the hardware acceleration of the BIG-IP.

References: Paper, ARS article, F5 blog entry.

RC4 attack

F5 Projected Threat Level - Low

Stream based ciphers like the older RC4 algorithm operate byte by byte and are immune to all of the above attacks. In the wake of the above attacks -- especially BEAST -- many people recommended using RC4.

However, RC4 has numerous statistical biases that may result in leakage of plaintext. In March 2013, djb (Daniel J Bernstein of the University of Chicago) revealed that with more than 2^24 samples of cipher text he could reliably statistically obtain the plaintext.

With this attack, a MITB attacker would repeatedly send the same message until enough cipher text was obtained. Strangely enough, while TLS renegotiation may help in the CBC attacks, in this case, key renegotiation is bad because the attacker wants to collect as many different ciphertexts of the same information as possible.

I know of no solution to this attack except to disable RC4.

F5 thinks this has a relatively low threat potential at the moment. This attack does have the potential to become practical If it’s ever seen in the wild, I would definitely recommend disabling RC4.

Reference: djb's slides, ARS article.

TIME Attack

F5 Projected Threat Level - Medium

In mid March 2013, Tal Be'Ery presented a refinement of the CRIME attack called TIME. CRIME worked against the compressed request, but TIME works against the compressed HTTP response. He also showed that a MITB could conduct the attack without a separate listener on the network, a significant improvement in the attack. Javascript in the browser measures the timing and infers the size of the HTTP response compressed block. Disabling HTTP compression will mitigate this attack. He recommends browser implementers make some changes to protect users.

He also recommends using the X-Frame-Options header in your app. This can easily be added by a BIG-IP.

This appears to be the most practical of all the attacks listed above. It’s possible that someday we could see this attack in the wild. Therefore, F5 currently considers this a medium threat.

Reference: slides, blog.

To summarize:

There is no alternative to CBC mode in the TLS specification. RFC 5288 describes a newer mode called Galois Counter Mode (GCM) that should fix the problem but very few browsers support AES-GCM.

So what cipher to use?

Disclaimer: This is speaking from my experience and what I’ve researched. F5 Networks doesn’t usually make recommendations about ciphers. You should do your own research before changing defaults.

If more clients supported it, my recommendation would be to use TLS 1.1 or TLS1.2 AES-CBC mode until we have new modes like GCM. BIG-IP v11.x or later can be set to use TLS 1.2 or TLS1.1 ciphers with a cipher string like "DEFAULT:!SSLv3:!TLSv1:!RC4". SOL13171 can be used to help you configure the BIG-IP.

You'll want to test with your clients; many clients don't support the newer ciphers yet.

If you can't disable TLS1.0 because you need the client support, then you have to choose between demonstrably weak RC4 and TLS1.0 AES-CBC which may vulnerable to BEAST. Most browsers have implemented the mitigation for the theoretical BEAST attack. The attack against RC4 proves it to be weak, so my recommendation would be to select AES-CBC mode with "DEFAULT:!SSLv3:!RC4".

Some popular websites have gone to RC4 over AES. I understand this choice, as a BEAST attack will take minutes to find your cookies, where an RC4 attack will take millions of messages before the entire message is cracked. However, the RC4 attack can only get better and someone may figure out how to narrow that down and use fewer messages to obtain the cookies. The BEAST attack is mitigated in many browsers.

At the moment, I can’t recommend disabling HTTP compression to foil the TIME attack. If that attack were seen in the wild, I would definitely recommend disabling HTTP compression.

F5 ASM mitigations

Almost all of these attacks currently rely on a MITB. Usually an attacker gets a MITB though a cross site request forgery (CSRF) flaw in an application. The ASM module of BIG-IP has CSRF protection that mitigates this risk.

ASM also has a domain cookie protection feature. If an attacker does obtain the authentication cookie, he must also obtain the rotating ASM cookie that contains a signature of all the other cookies.

These features should make it significantly harder for an attacker to obtain cookies using any of the methods above.

Conclusion

I’d like to thank my generous F5 colleagues who helped me research these attacks. It’s been a fascinating journey into crypto. You can be assured that F5 will continue to keep an eye on these attacks and will continue to work with browsers and researchers to implement safe and secure protocols.