Posted by Adam Langley, Software Engineer
SSL/TLS combines a number of choices about cryptographic primitives, including the choice of cipher, into a collection that it calls a “cipher suite.” A
list of cipher suites is maintained by the Internet Assigned Names and Numbers Authority.
Because of recent research, this area of TLS is currently in flux as older, flawed, cipher suites are deprecated and newer replacements introduced into service. In this post we’ll be discussing known flaws in some of them.
Cipher suites are written like this: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, which breaks down into the following parts:
ECDHE: the key agreement mechanism.
RSA: the authentication mechanism.
AES_128_CBC: the cipher.
SHA: the message authentication primitive.
For this discussion, only the ‘cipher’ part of the cipher suite is pertinent.
RC4
RC4 is a very common stream cipher but is showing its 26-year age.
Biases in the RC4 keystream have been known for over a decade or more [
1][
2][
3][
4] and were used to attack WEP, the original security standard for Wi-Fi. HTTPS was believed to be substantially unaffected by these results until Paterson et al compiled and extended them [
5] and demonstrated that belief to be incorrect.
The best, known attack against using RC4 with HTTPS involves causing a browser to transmit many HTTP requests -- each with the same cookie -- and exploiting known biases in RC4 to build an increasingly precise probability distribution for each byte in a cookie. However, the attack needs to see on the order of 10 billion copies of the cookie in order to make a good guess. This involves the browser sending ~7TB of data. In ideal situations, this requires nearly three months to complete.
This attack cannot be mitigated without replacing RC4.
AES-CBC
AES-CBC has a couple of problems, both of which are problems with the way that TLS uses CBC (Cipher Block Chaining) mode, and not problems with AES.
The first is called
BEAST and was demonstrated by Duong and Rizzo 2011 (although the idea was originally
described by Rogaway in 1995). It exploits a flaw in the way that TLS prior to version 1.1 generated CBC initialization vectors.
The attack requires precise control over the TLS connection which is not generally possible from a vanilla browser; the demo used a Java applet to obtain this control. The version of the WebSockets protocol used at the time may have allowed the necessary degree of control, but that had already been replaced by the time that the issue was demonstrated.
However, browsers are complex and evolving pieces of software, and the necessary degree of control is certainly not a comfortable barrier to exploitation. If possible, the exploit is very practical. It requires the attacker to have access to the network near the computer but otherwise completes quickly and deterministically.
The issue is fixed either by using TLS >= 1.1, or by a trick called 1/n-1 record splitting, which has been implemented by all major browsers now. However, many older installations may still exist with Java enabled and would thus be vulnerable to this attack.
The second issue is called
Lucky13. This attack uses the fact that TLS servers take a slightly different amount of time to process different types of invalid TLS records. This attack is the first one that we have discussed that requires the use of timing side-channels and is thus probabilistic.
The attack needs nearly 10,000 TLS connections per byte of plaintext decoded and the attacker needs to be situated close to the TLS server in order to reduce the amount of timing noise added by the network. Under absolutely ideal situations, an attacker could extract a short (16 byte) cookie from a victim's browser in around 10 minutes. With optimistic but plausible parameters, the attack could work in an hour.
This attack can only be fixed at the server by making the decoding of all CBC records take a constant amount of time. It’s not plausible for a browser to detect whether a server has fixed this issue before using AES-CBC.
AES-GCM
There are no known breaks of AES-GCM and it is one of the ciphers that TLS servers are urged to support. However it suffers from a couple of practical issues:
The first is that it’s very challenging to implement AES-GCM in software in a way which is both fast and secure. Some CPUs implement AES-GCM directly in hardware (this is called AES-NI by Intel, the most prominent example of this) and these CPUs allow for implementations that are secure and very fast, but hardware support is far from ubiquitous.
The second nit with AES-GCM is that, as integrated in TLS, implementations are free to use a random nonce value. However, the size of this nonce (8 bytes) is too small to safely support using this mode. Implementations that do so are at risk of a catastrophic nonce reuse after sending on the order of a terabyte of data on a single connection. This issue can be resolved by using a counter for the nonce but using random nonces is the most common practice at this time.
When both parties to a TLS connection support hardware AES-GCM and use counters, this cipher is essentially optimal.
ChaCha20-Poly1305
This cipher (technically an AEAD, not a cipher, as is AES-GCM) also has no known breaks but is designed to facilitate fast and secure software implementations. For situations where hardware AES-GCM support is not available, it provides a fast alternative. Even when AES-GCM hardware is provided, ChaCha20-Poly1305 is currently within a factor of two in speed.
Summary
While we recommend the world move to support TLS 1.2, AES-GCM and ChaCha20-Poly1305 (as Chrome and Google are doing) we have to deal with a large fraction of the Internet that moves more slowly than we would like. While RC4 is fundamentally flawed and must be replaced, the attacks against it are very costly. The attacks against CBC mode, however, are much more practical and only one can be conclusively addressed on the client side. It is not clear which is best when nothing better is available.
TLS 1.2 is needed in order to use AES-GCM and ChaCha20-Poly1305. TLS 1.2 deployment is hampered by older servers that fail to process valid TLS messages and thus break version negotiation. It also remains to be seen whether firewalls and other network intermediaries are erroneously processing TLS connections that pass through them, breaking TLS 1.2. Chrome 32 includes an experiment that tests for this issue. If TLS 1.2 is found to be viable on the modern Internet, remedial measures can be taken to repair the TLS version negotiation without breaking the previously mentioned, flawed TLS servers.