2013 IEEE Symposium on Security and Privacy Lucky Thirteen: Breaking the TLS and DTLS Record Protocols Nadhem J. AlFardan and Kenneth G. Paterson Information Security Group, Royal Holloway, University of London Egham, Surrey TW20 0EX, UK Email: {nadhem.alfardan.2009, kenny.paterson}@rhul.ac.uk Abstract—The Transport Layer Security (TLS) protocol to build a secure channel for transporting application-layer aims to provide confidentiality and integrity of data in transit data. Other major components are the (D)TLS Handshake de facto across untrusted networks. TLS has become the secure Protocol, which is responsible for authentication, session protocol of choice for Internet and mobile applications. DTLS is a variant of TLS that is growing in importance. In this key establishment and ciphersuite negotiation, and the TLS paper, we present distinguishing and plaintext recovery attacks Alert Protocol, which carries error messages and manage- against TLS and DTLS. The attacks are based on a delicate ment traffic. Setting aside dedicated authenticated encryption timing analysis of decryption processing in the two protocols. algorithms (which are yet to see widespread support in TLS We include experimental results demonstrating the feasibility of or DTLS implementations), the (D)TLS Record Protocol the attacks in realistic network environments for several differ- ent implementations of TLS and DTLS, including the leading uses a MAC-Encode-Encrypt (MEE) construction. Here, the OpenSSL implementations. We provide countermeasures for plaintext data to be transported is first passed through a the attacks. Finally, we discuss the wider implications of our MAC algorithm (along with certain header bytes) to create attacks for the cryptographic design used by TLS and DTLS. a MAC tag. The supported MAC algorithms are all HMAC- Keywords-TLS, DTLS, CBC-mode encryption, timing attack, based, with MD5, SHA-1 and SHA-256 being the allowed plaintext recovery hash algorithms in TLS 1.2 [9]. Then an encoding step takes place. For the RC4 stream cipher, this just involves I. INTRODUCTION concatenation of the plaintext and the MAC tag, while for CBC-mode encryption (the other possible option), the TLS is arguably the most widely-used secure communica- plaintext, MAC tag, and some encryption padding of a tions protocol on the Internet today. Starting life as SSL, the specified format are concatenated. In the encryption step, protocol was adopted by the IETF and specified as TLS 1.0 the encoded plaintext is encrypted with the selected cipher. [7]. It has since evolved through TLS 1.1 [8] to the current In the case where CBC-mode is selected, the block cipher version TLS 1.2 [9]. Various other RFCs define additional is DES, 3DES or AES (with DES being deprecated in TLS TLS cryptographic algorithms and extensions. TLS is now 1.2). Following [18], we refer to this MEE construction as used for securing a wide variety of application-level traffic MEE-TLS-CBC. We provide greater detail on its operation and has become a serious rival to IPsec for general VPN in the (D)TLS Record Protocol in Section II. usage. It is widely supported in client and server software The widespread use of TLS (and the increasing use and in cryptographic libraries for embedded systems, mobile of DTLS) makes the continued study of the security of devices, and web application frameworks. these protocols of great importance. Indeed, the evolution The DTLS protocol is a close relative of TLS, developed of the TLS Record Protocol has largely been driven by from TLS by making minimal changes so as to allow it cryptographic attacks that have been discovered against it, to operate over UDP instead of TCP [16]. This makes including those in [25], [5], [17], [3], [4], [10], [18], [1]. DTLS suitable for use where the costs of TCP connection Of particular interest lately have been attacks based on the establishment and TCP retransmissions are not warranted, use of chained initialisation vectors (IVs) for CBC-mode for example, in voice and gaming applications. DTLS exists in SSL and TLS 1.0, in particular, the so-called BEAST in two versions, DTLS 1.0 [20], which roughly matches TLS attack [10] which has its roots in [23], [17], [3], [4]. This 1.1 and DTLS 1.2 [21], which aligns with TLS 1.2. attack achieved full plaintext recovery against TLS, but Both TLS and DTLS are actually protocol suites, rather only in scenarios where an attacker can gain access to a than single protocols. The main component of (D)TLS that chosen plaintext capability, perhaps by inducing the user to concerns us here is the Record Protocol, which uses sym- first download malicious javascript code into his browser. metric key cryptography (block ciphers, stream ciphers and Despite this strong requirement, the BEAST attack attracted MAC algorithms) in combination with sequence numbers significant industry and media attention in 2011. Amongst The second author’s research was supported by an EPSRC Leadership the possible countermeasures are upgrading to TLS 1.1 or Fellowship, EP/H005455/1. 1.2, the inclusion of a dummy zero-length message prior to 1081-6011/13 $26.00 © 2013 IEEE 526 DOI 10.1109/SP.2013.42 each real TLS message, or the abandonment of CBC-mode The applicability of the attacks is also implementation- encryption in favour of RC4 or an authenticated encryption dependent, because of the manner in which different imple- algorithm. mentations interpret the RFCs. We have investigated several The other major line of attacks against the TLS Record different open-source implementations of TLS and DTLS, Protocol comprises [25], [5], [17], [18], [1] and relates and found all of them to be vulnerable to our new attacks to how the padding that is required in MEE-TLS-CBC is or variants of them (or even old attacks in one case). handled during decryption. The problems here all stem from We have implemented a selection of the attacks in an the fact that the padding is added after the MAC has been experimental setting. As with earlier attacks, completely computed and so forms unauthenticated data in the encoded breaking TLS is challenging because the attacks create plaintext. Taken altogether, the attacks in [25], [5], [17], [18], “broken” TLS records and so consume many TLS sessions. [1] show that handling padding arising during decryption Nevertheless, our basic attack can extract full plaintext processing is a delicate and complex issue for MEE-TLS- for the current OpenSSL implementation of TLS assuming CBC. the attacker is located, say, in the same LAN segment as It is the case that all these attacks on CBC-mode in the targeted TLS client or server, using roughly 223 TLS TLS could be avoided by adopting RC4 or a dedicated sessions to reliably recover a block of plaintext in a multi- authenticated encryption mode, or perhaps by redesigning session attack scenario like that considered in [5]. Such a (D)TLS to use only an Encrypt-then-MAC construction. scenario is applicable when, for example, an application pro- However, RC4 is not an option for DTLS, and not NIST- tocol performs automatic TLS reconnection and password recommended for TLS [6]; meanwhile authenticated encryp- retransmission. Given its complexity, this basic attack would tion modes are only available in TLS 1.2, which is not seem to present only a theoretical threat. However, variants 1 yet widely supported. Redesigning (D)TLS would require of it are much more effective: even more radical changes than adopting TLS 1.2. So it would be fanciful to “wish away” MEE-TLS-CBC, and all • The distinguishing attacks against TLS are quite prac- the complexity that this entails: this is an option that is tical for OpenSSL, requiring just a handful of sessions firmly embedded in the TLS and DTLS RFCs, in widespread in order to reliably tell apart the encryptions of chosen use, and will remain so for the foreseeable future. On the messages. other hand, we might hope that after more than a decade of • Breaking DTLS implementations is fully practical even intensive study, we would have arrived at a point where we for a remote attacker, since we can exploit the fact that understand how to implement MEE-TLS-CBC securely. In DTLS errors are non-fatal to mount the attacks in a this paper, we show that this is not the case. single session, and reuse the amplification techniques from [1] to boost the delicate timing signals on which A. Our Results our attacks depend. We present a family of attacks that apply to CBC-mode • We also have more efficient partial plaintext recov- in all TLS and DTLS implementations that are compliant ery attacks on TLS and DTLS. For example, against with TLS 1.1 or 1.2, or with DTLS 1.0 or 1.2. They also OpenSSL TLS, an attacker who knows one byte of a apply to implementations of SSL 3.0 and TLS 1.0 that block in either of the last two byte positions can reliably incorporate padding oracle attack countermeasures (imple- recover each of the remaining bytes in that block using mentations that do not are of course already vulnerable to 216 sessions. known attacks). • The complexity of all our attacks can be reduced using The attacks come in various distinguishing, partial plain- language models and sequential statistical techniques text recovery, and full plaintext recovery flavours. For the as in [5], [10]. As a simple example, if the plaintext plaintext recovery attacks, no chosen-plaintext capability is is base64 encoded, as is the case for HTTP basic needed, in contrast to the BEAST attacks: the attacks can be access authentication and cookies, then the number of mounted by a standard man-in-the-middle (MITM) attacker TLS sessions needed to recover a block reduces from who sees only ciphertext and can inject ciphertexts of his roughly 223 to 219.