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

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 "Bleichenbacher-oracle" 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.