On the Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 v1.5 Encryption Tibor Jager Jörg Schwenk Juraj Somorovsky Horst Görtz Institute Horst Görtz Institute Horst Görtz Institute Ruhr University Bochum Ruhr University Bochum Ruhr University Bochum [email protected] [email protected] [email protected] ABSTRACT Categories and Subject Descriptors Encrypted key transport with RSA-PKCS#1 v1.5 is the most com- C.2.2 [Computer-Communication Networks]: Network Proto- monly deployed key exchange method in all current versions of the cols; K.4.4 [Computers and Society]: Electronic Commerce – Transport Layer Security (TLS) protocol, including the most re- Security cent version 1.2. However, it has several well-known issues, most importantly that it does not provide forward secrecy, and that it is prone to side channel attacks that may enable an attacker to learn Keywords the session key used for a TLS session. A long history of attacks Cross-protocol attack; chosen-ciphertext attack; TLS shows that RSA-PKCS#1 v1.5 is extremely difficult to implement securely. The current draft of TLS version 1.3 dispenses with this encrypted key transport method. But is this sufficient to protect 1. INTRODUCTION against weaknesses in RSA-PKCS#1 v1.5? We describe attacks which transfer the potential weakness of TLS and PKCS#1 v1.5 encryption. Transport layer security (TLS) prior TLS versions to two recently proposed protocols that do not is the most important security protocol on the Internet. It is very even support PKCS#1 v1.5 encryption, namely Google’s QUIC pro- flexible, as it allows two communicating parties to negotiate the tocol and TLS 1.3. These attacks enable an attacker to impersonate cryptographic algorithms used for a TLS connection at the begin- a server by using a vulnerable TLS-RSA server implementation as ning of each session. For each new TLS session, the peers may a “signing oracle” to compute valid signatures for messages chosen choose from different selections of cryptographic algorithms for by the attacker. key establishment, symmetric encryption, and message authentica- The first attack (on TLS 1.3) requires a very fast “Bleichenbacher- tion. The current TLS version is 1.2 [12], it was published in 2008. oracle” to create the TLS CertificateVerify message before All current TLS versions include RSA-based PKCS#1 v1.5 en- the client drops the connection. Even though this limits the prac- cryption [24]. Even though this scheme has been updated [21, tical impact of this attack, it demonstrates that simply removing 19] and has been subject to many attacks [7, 22, 9, 18, 4, 28, a legacy algorithm from a standard is not necessarily sufficient to 36] (in TLS and other applications), it is the most commonly used protect against its weaknesses. method for TLS key establishment in practice. Moreover, the only The second attack on Google’s QUIC protocol is much more mandatory-to-implement cipher suite in TLS 1.2 is based on this practical. It can also be applied in settings where forging a sig- encryption scheme. nature with the help of a “Bleichenbacher-oracle” may take an ex- TLS 1.3. Version 1.3 of TLS is currently under development [13]. tremely long time. This is because signed values in QUIC are inde- It is the first version which dispenses with PKCS#1 v1.5 encryp- pendent of the client’s connection request. Therefore the attacker tion. There are several reasons for this, including the lack of for- is able to pre-compute the signature long before the client starts a ward secrecy, that the PremasterSecret of previous TLS ver- connection. This makes the attack practical. Moreover, the impact sions may depend only on client randomness, and that PKCS#1 on QUIC is much more dramatic, because creating a single forged v1.5 encryption has proven to be extremely difficult to implement signature is essentially equivalent to retrieving the long-term secret securely in TLS [7, 22, 4, 28]. key of the server. In this paper, we analyze the security of the current version of the TLS 1.3 draft against weaknesses in PKCS#1 v1.5 encryption. We show that even though this encryption scheme is not even used in TLS 1.3, the coexistence with older TLS versions may enable cross-protocol attacks [33, 26]. Permission to make digital or hard copies of all or part of this work for personal or Google’s QUIC protocol. Quick UDP Internet Connections (QUIC) classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation [32] is a key-exchange protocol based on UDP connections, which on the first page. Copyrights for components of this work owned by others than the aims at reducing the relatively high latency of protocols like TLS. author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or The latency in TLS(-over-TCP) stems from the handshake mes- republish, to post on servers or to redistribute to lists, requires prior specific permission sages (for both TCP and TLS) to be sent before the first encrypted and/or a fee. Request permissions from [email protected]. message can be transmitted. QUIC’s goal is to reduce the number CCS’15, October 12–16, 2015, Denver, Colorado, USA. of “round trips” for key establishment to a minimum, while provid- Copyright is held by the owner/author(s). Publication rights licensed to ACM. ACM 978-1-4503-3832-5/15/10 ...$15.00. ing all security guarantees expected from a key-exchange protocol DOI: http://dx.doi.org/10.1145/2810103.2813657. on the Internet. QUIC is currently considered experimental, but put forward by 3. While Bleichenbacher’s attack and its early applications [7, Google and implemented in recent versions of Google’s Chrome 22] were originally rather inefficient, much faster versions web browser, the Opera browser, and available on Google web are known today [25, 4]. This makes such attacks applicable servers. Google has announced that QUIC will be proposed as an in settings where they were previously considered infeasible. IETF standard.1 Currently, draft version 01 is available.2 Thus, in summary, PKCS#1 v1.5 encryption has proven to be Relevance and recurrence of Bleichenbacher attacks. At Crypto extremely difficult to implement securely. Considering all possible 1998 [7] Bleichenbacher presented a seminal attack on RSA-based side channels (some of which might not even be conceivable today) PKCS#1 v1.5 encryption. Essentially, it assumes the existence of seems virtually impossible. an “oracle” that allows an attacker to distinguish “valid” from “in- valid” PKCS#1 v1.5-padded ciphertexts. Such an oracle may in Transferring the weaknesses of PKCS#1 v1.5 encryption to mod- practice be given by a TLS server, which responds with appropriate ern protocols. For the reasons explained above, it seems a wise de- error messages, or allows in any other way to tell whether a given cision that PKCS#1 v1.5 encryption is not used in QUIC and will ciphertext has a “valid” padding or not (for instance by observing finally be removed from TLS in version 1.3. However, the question the timing behavior of the server when processing the ciphertext). that motivates our research is the following: Bleichenbacher showed that such an oracle is sufficient to decrypt Is this sufficient to protect TLS 1.3 and QUIC against the PKCS#1 v1.5 ciphertexts. Today there exist many variants and re- weaknesses of PKCS#1 v1.5 encryption? finements of this attack [7, 22, 9, 18, 4, 28, 36], the TLS RFCs [10, 11, 12] give recommendations for implementing PKCS#1 v1.5 en- We analyze the security of both protocols under the hypothe- cryption securely (which are however kept quite general). sis that Bleichenbacher-like attacks on PKCS#1 v1.5 encryption in One may think that seventeen years after the publication of Ble- TLS versions prior to 1.3 will remain a realistic threat in the future, ichenbacher’s attack we should have developed a very good under- and study the impact of such attacks on TLS 1.3 and QUIC. standing of this weakness, and that at least important, widely-used For the analysis of TLS 1.3, we consider a setting where there is applications that still use this scheme (possibly for legacy reasons, a TLS client C that supports only TLS 1.3, and thus may expect that like TLS) finally implement it securely. However, there is vast evi- it is immune against weaknesses in PKCS#1 v1.5 encryption. The dence that this belief is false: client connects to a server S, which offers TLS 1.3, and at least one 1. Increasingly sophisticated analysis techniques and new side previous TLS version which allows to use PKCS#1 v1.5 encryp- channels allow one to apply Bleichenbacher-like attacks in tion, say TLS 1.2. Note that today’s TLS servers are typically not settings where these attacks were previously believed to be configured to offer only the most recent TLS version 1.2 (or any impossible. A recent example was described at USENIX Se- other single version), but they usually offer many TLS versions in curity 2014 by Meyer et al. [28]. The authors discover new parallel, to maximize compatibility with different TLS clients. Ac- timing-based side channels that allow one to apply Bleichen- cording to SSL Pulse [1], TLS 1.2 and 1.1 are supported by about bacher’s attack to widely-used TLS implementations, like 60%, and TLS 1.0 is supported by nearly 100% of the TLS servers Java’s JSSE or hardware security appliances using Cavium’s analyzed in April 2015.