Introduction:

This page is about the Lucky 13 attack on CBC-mode encryption in TLS. For details on the security of RC4 encryption in TLS, click here.

The Transport Layer Security (TLS) protocol aims to provide confidentiality and integrity of data in transit across untrusted networks like the Internet. It is widely used to secure web traffic and e-commerce transactions on the Internet. Datagram TLS (DTLS) is a variant of TLS that is growing in importance. We have found new attacks against TLS and DTLS that allow a Man-in-the-Middle attacker to recover plaintext from a TLS/DTLS connection when CBC-mode encryption is used. The attacks arise from a flaw in the TLS specification rather than as a bug in specific implementations. We have carried out experiments to demonstrate the feasibility of the attacks against the OpenSSL and GnuTLS implementations of TLS, and we have studied the source code of other implementations to determine whether they are likely to be vulnerable. There are effective countermeasures against our attacks and we have worked with a number of TLS and DTLS software developers to prepare patches and security advisories.

Who are we?

The team behind this research comprises Nadhem AlFardan and Kenny Paterson. Nadhem is a PhD student in the Information Security Group at Royal Holloway, University of London. Kenny is a Professor of Information Security and an EPSRC Leadership Fellow in the Information Security Group. We have previous experience in analysing secure network protocols, including IPsec, SSH, SSL/TLS and DTLS.

What is affected?

Which versions of TLS and DTLS are affected?

The attacks apply to all TLS and DTLS implementations that are compliant with TLS 1.1 or 1.2, or with DTLS 1.0 or 1.2. They also apply to implementations of SSL 3.0 and TLS 1.0 that incorporate countermeasures to previous padding oracle attacks. Variant attacks may also apply to non-compliant implementations.

Which TLS and DTLS ciphersuites are affected?

All TLS and DTLS ciphersuites which include CBC-mode encryption are potentially vulnerable to our attacks.

Which TLS and DTLS implementations are affected?

We have tested our attacks against OpenSSL and GnuTLS. For OpenSSL, a full plaintext recovery attack is possible. For GnuTLS, a partial plaintext recovery attack is possible, recovering up to 4 bits of the last byte in any block of plaintext. We have examined the source code of the NSS, PolarSSL, yaSSL, BouncyCastle and OpenJDK implementations of TLS. They are all potentially vulnerable to our attacks. We have not studied any closed-source implementations of TLS.

How severe are the attacks?

We have discovered a variety of attacks, each having different complexity and severity. For TLS, our attacks are multi-session attacks, which means that we require the target plaintext to be repeatedly sent in the same position in the plaintext stream in multiple TLS sessions. The attacks involve detecting small differences in the time at which TLS error messages appear on the network in response to attacker-generated ciphertexts. Because of network jitter and other effects, the times observed by the attacker are noisy, and multiple samples of each time are needed to make the attacks reliable. In their simplest form, our attacks can reliably recover a complete block of TLS-encrypted plaintext using about 223 TLS sessions, assuming the attacker is located on the same LAN as the machine being attacked and HMAC-SHA1 is used as TLS's MAC algorithm. This can be reduced to 219 TLS sessions if the plaintext is known to be base64 encoded. This can be further reduced to 213 sessions per byte if a byte of plaintext in one of the last two positions in a block is already known. The attack complexities are different for different MAC algorithms. Further details can be found in our research paper.

The sessions needed for our attacks on TLS can be generated in various ways. The attacks cause the TLS session to be terminated, and some applications running over TLS automatically reconnect and retransmit a cookie or password. In a web environment, the sessions may also be generated by client-side malware, in a similar way to the BEAST attack. Unlike BEAST, no exploit is needed to bypass the same origin policy in the web browser, since the attacker does not require the ability to inject plaintext blocks into the TLS session. And, with the BEAST-style enhancements, the attacker no longer needs to know one out of two bytes of plaintext at the end of the block, so that full plaintext recovery of the full base64 encoded plaintext is possible using 213 sessions per byte.

For DTLS, the attacks can be carried out in a single session, and known amplification techniques can be used to boost the timing signals relative to the noise. (Further details of these techniques can be found in our NDSS12 paper.) The attacks are fully practical for DTLS. For further details, see the research paper.

How does this work relate to known attacks, like BEAST and CRIME?

TLS in CBC-mode has been the subject of several attacks over the years, most notably padding oracle attacks and the BEAST attack. For more details of prior attacks, see our research paper. However, there are countermeasures for both of these attacks, and TLS in CBC-mode was believed to be secure once these countermeasures were applied. Our research shows that this is not the case. In particular, the advice to implementors in the TLS RFCs concerning how to avoid padding oracle attacks does not remove all possible timing side channels.

Wasn't TLS in CBC-mode recently proven to be secure?

Yes, a recent paper of Paterson, Ristenpart and Shrimpton (Asiacrypt 2011) showed that the TLS Record Protocol meets a strong notion of cryptographic security, but their proof holds under the assumption that an attacker cannot discern the cause of TLS decryption failures. Our new research shows that this assumption is not met by TLS implementations, even when they follow the implementation advice in the TLS RFCs.

How do the attacks relate to BEAST and CRIME?

The attacks are quite different from BEAST and CRIME. BEAST exploits the inadvisable use of chained IVs in CBC-mode in SSL and TLS 1.0. CRIME cleverly exploits the use of compression in TLS. Our attacks are based on analysing how decryption processing is carried out in TLS. However, our attacks can be enhanced by combining them with BEAST-style techniques.

How do the attacks relate to padding oracle attacks?

At a high level, the attacks can be seen as an advanced form of padding oracle attack. In more detail, the attacks rely on the fact that, for certain carefully chosen message lengths and when the HMAC-SHA1 MAC algorithm is used, then TLS messages containing at least two bytes of correct padding will be processed slightly faster than TLS messages containing one byte of correct padding or padding that is incorrectly formatted. This is because of a fortuitous alignment of TLS header bytes, plaintext bytes and MAC tag bytes with the block cipher's block boundary and the hash compression function's block boundary. The timing difference corresponds to the time taken for a single hash function compression function evaluation, on the order of a few hundred clock cycles on a modern processor. This timing difference is detected over the network in our attack, by timing the arrival of TLS error messages. By repeating the attack sufficiently often and using careful statistical processing, the noise arising from network jitter and other sources can be overcome and the different padding conditions can be differentiated from one another. Thus an attacker can distinguish messages containing at least two bytes of correct padding from all other patterns. At this point, a variant of the standard padding oracle attack can be carried out. For further details, please see our research paper.

Why are the attacks called "Lucky Thirteen"?

In Western culture, 13 is considered an unlucky number. However, the fact that the TLS MAC calculation includes 13 bytes of header information (5 bytes of TLS header plus 8 bytes of TLS sequence number) is, in part, what makes the attacks possible. So, in the context of our attacks, 13 is lucky - from the attacker's perspective at least. This is what passes for humour amongst cryptographers.

What are the countermeasures?

There are several possible countermeasures against our attacks, some of which are more effective than others:

  • Add random time delays to CBC-mode decryption processing. As we explain in more detail in our research paper, this is ineffective, since the effect of the delays can be averaged out by taking more timing samples.
  • Switch to using RC4 ciphersuites. This should only be seen as a temporary measure, since RC4 has significant cryptographic weaknesses when it is used in TLS. This option is not available for DTLS.
  • Switch to using AEAD ciphersuites, such as AES-GCM. Support for AEAD ciphersuites was specified in TLS 1.2, but this version of TLS is not yet widely supported. We hope that our research will spur support for TLS 1.2 in client and server implementations.
  • Modify TLS's CBC-mode decryption procedure so as to remove the timing side channel Our research paper describes one method for doing this that is being adopted by some vendors. Other approaches are also possible. However, some care is needed in implementations to completely remove the timing side channel that our attacks exploit. Our recommendation for the long term is to avoid using TLS in CBC-mode and to switch to using AEAD algorithms.

Patches, advisories and press

We have worked closely with the IETF TLS Working Group to disclose our attacks. OpenSSL, NSS, GnuTLS, yaSSL, PolarSSL, Opera, and BouncyCastle have released patches to protect TLS in CBC-mode against our attacks. We have advised on patch development and, in several cases, we have tested patches on behalf of the individual vendors. We have also informed several other vendors about our work, including Apple, Cisco, Microsoft and Oracle. Further details:

  • OpenSSL: the attacks are addressed in versions 1.0.1d, 1.0.0k and 0.9.8y, released 05/02/2013.
  • NSS: the attacks are addressed in version 3.14.3, released 15/02/2013.
  • GnuTLS: the attacks are addressed in versions 2.12.23, 3.0.28 and 3.1.7, released 04/02/13.
  • PolarSSL: the attacks are addressed in version 1.2.5, released 03/02/13.
  • CyaSSL: the attacks are addressed in version 2.5.0, released 04/02/2013.
  • MatrixSSL: the attacks are addressed in version 3.4.1, released 06/02/13.
  • Opera: the attacks are addressed in Opera version 12.13, released 30/01/2013.
  • F5: have informed us that their TLS dataplane traffic is not vulnerable due to cryptographic offload, but that local management ports and virtual editions may be vulnerable. For more details, see the F5 security advisory.
  • BouncyCastle: the attacks are addressed in version 1.48 of the Java library, released 10/02/2013. The C# version of BouncyCastle will be fixed in CVS at a similar time, and included in release 1.8 at a later date.
  • Oracle (Java): the attacks are addressed in a special critical patch update of JavaSE, released 19/02/2013.

We will add more information here about individual vendor's advisories as they become available.

Selected press coverage:

Is it still safe to use TLS?

The attacks can only be carried out by a determined attacker who is located close to the machine being attacked and who can generate sufficient sessions for the attacks. In this sense, the attacks do not pose a significant danger to ordinary users of TLS in their current form. However, it is a truism that attacks only get better with time, and we cannot anticipate what improvements to our attacks, or entirely new attacks, may yet to be discovered. In addition, because of its extremely widespread use, any attack against TLS requires careful evaluation. In this context, it is notable that the leading TLS implementations are deploying countermeasures to our attacks.

Source code

We have no plans to make the source code generally available. If you are a researcher interested in replicating or extending our work, then please contact us.

Isn't it irresponsible to publish attacks on such important protocols?

In short, no. Our long-term aim is to ensure that weak encryption options are eliminated from TLS, to the eventual benefit of all users of TLS. Experience shows that the only way to make this happen is to make the attacks as powerful as possible and build proof-of-concept implementations of them. We have expended significant research effort to develop and prototype our attacks. We disclosed the attacks to affected vendors well in advance of making our research public, and we worked with any vendor who requested our assistance in assessing the attacks and implementing countermeasures.

For more information

Please read our research paper describing the attacks and mitigations. If you have remaining questions after having read the paper, please contact us via e-mail.