On the Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 v1.5 Encryption

Abstract

Encrypted key transport with RSA-PKCS#1 v1.5 is the most commonly deployed key exchange method in all current versions of the Transport Layer Security (TLS) protocol, including the most recent 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 the session key used for a TLS session. A long history of attacks 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 against weaknesses in RSA-PKCS#1 v1.5? We describe attacks which transfer the potential weakness of prior TLS versions to two recently proposed protocols that do not even support PKCS#1 v1.5 encryption, namely Google's QUIC protocol and TLS 1.3. These attacks enable an attacker to impersonate a server by using a vulnerable TLS-RSA server implementation as a "signing oracle" to compute valid signatures for messages chosen by the attacker. The first attack (on TLS 1.3) requires a very fast "Bleichenbacheroracle" to create the TLS CertificateVerify message before the client drops the connection. Even though this limits the practical impact of this attack, it demonstrates that simply removing a legacy algorithm from a standard is not necessarily sufficient to protect against its weaknesses. The second attack on Google's QUIC protocol is much more practical. It can also be applied in settings where forging a signature with the help of a "Bleichenbacher-oracle" may take an extremely long time. This is because signed values in QUIC are independent of the client's connection request. Therefore the attacker is able to pre-compute the signature long before the client starts a connection. This makes the attack practical. Moreover, the impact on QUIC is much more dramatic, because creating a single forged signature is essentially equivalent to retrieving the long-term secret key of the server.

Verified Models and Reference Implementations for the TLS 1.3 Standard Candidate

“…This attack found by ProVerif directly corresponds to the cross-protocol Bleichenbacher attacks described in [53,8]. It shows that removing RSA key Inria transport from TLS 1.3 is not enough, one must disable the use of TLS 1.2 RSA mode on any server whose certificate may be accepted by a TLS 1.3 client.…”

“…A version downgrade attack was found in Draft-12 and its countermeasure in Draft-13 was proved secure [16]. A cross-protocol attack on RSA signatures was described in [53]. Even in this paper, we describe two vulnerabilities in 0-RTT client authentication that we discovered and reported, which influenced the subsequent designs of Draft-7 and -13.…”

“…Although countermeasures to this attack have been incorporated into TLS, they remains hard to implement securely [65] resulting in continued attacks such as DROWN [8]. Furthermore, such padding oracles can sometimes even be converted to signature oracles for the corresponding private key [53].…”

“…Second, none of these symbolic or cryptographic analyses, with the exception of [16], consider the composition of TLS 1.3 with legacy versions like TLS 1.2. Hence, they do not account for attacks like [53] that exploit weak legacy crypto in TLS 1.2 to break the modern cryptographic constructions of TLS 1.3. Third, none of these works addresses TLS 1.3 implementations.…”

Generic Forward-Secure Key Agreement Without Signatures

“…We note that this is not just a theoretical concern. Attacks against deployed cryptography that reuse keys in unintended ways have been previously reported [27,19,20].…”