TLS 1.3 Security against PKCS#1v1.5

Question

This paper explains an attack on TLS 1.3. This was published way back in 2015 when TLS RFC was in draft stage.
My question is now TLS 1.3 RFC is finalized, is this attack got addressed?

Answer 1

There is an encryption scheme called RSAES-PKCS1-v1_5, or PKCS#1v1.5 for short. There is a signature scheme called RSASSA-PKCS1-v1_5, or PKCS#1v1.5 for short. These two schemes have different security postures.

The signature scheme has no particular weakness as long as the implementation is functionally correct and the use of the private key has no exploitable side channel leak. There is a class of attacks against PKCS#1v1.5 due to Bleichenbacher, but it's due to implementations of signature verification that don't verify everything they should. Vulnerable implementations still existed in 2019, but major implementations of PKCS#1v1.5 have been safe for ages.

The encryption scheme is extremely difficult to implement correctly because decryption is vulnerable to padding oracle attacks. Some ciphertexts are invalid, and merely revealing whether a ciphertexts is valid or not, even through a very small timing difference, is enough to allow attackers to decrypt arbitrary ciphertexts. To make matters worse, revealing partial information about a plaintext after a successful decryption can also allow the attack. This class of attacks is also due to Bleichenbacher (there's also a similar class of attacks known as Manger's attack). There was a big wave of disclosures in late 2018 nicknamed “the 9 lives of Bleichenbacher's CAT”, and it's probably not the last one. PKCS#1v1.5 encryption is extremely hard to implement and use correctly and many voices are calling to stop using it altogether.

TLS up to 1.2 has cipher suites that use RSA encryption: the client encrypts a master secret, the server decrypts it, this master secret becomes a shared key for the subsequent communication, and the client knows that it's talking to the correct server because only the correct server can decrypt the master secret. TLS also has cipher suites that use RSA signatures: the two parties perform an unauthenticated key agreement to establish a master secret, the server signs the handshake data, and the client verifies the signature to ensure that it's talking to the correct server.

If a server is willing to use a cipher suite that uses RSA decryption, and there is a vulnerability that allows attackers to use the server as a decryption oracle, this vulnerability may also allow attackers to use the server as a signature oracle. If this is the case, then attackers can impersonate the server even against clients who refuse to use RSA decryption. The attack goes like this:

• The client starts a handshake. The attacker is a man-in-the-middle and intercepts the handshake packets. The client and the attacker agrees to use a TLS cipher suite based on RSA signature.
• The attacker needs to sign the handshake data. It contacts the server, which is willing to perform RSA decryption. The attacker uses the server as an oracle to construct a signature of the handshake.
• The attacker sends the valid signature to the client, so the client believes that it is talking to the correct server.

This attack is possible even if the client uses TLS 1.3, which only has cipher suites based on RSA signature (as well as cipher suites using other signature schemes), not RSA encryption. The root of the problem is that the server is willing to do RSA decryption and RSA signature with the same key.

This is an illustration of the fact that it's bad practice to use the same key for two different purposes. A protocol definition cannot protect against this (other than to say “don't do it”, but it's not something that the other side can detect).

Answer 2

The attack portrayed is that you use Bleichenbacher's Oracle on some system which does PKCS#1v1.5 (thus can't be TLS 1.3) and then you use the Oracle results to impersonate that same system on TLS 1.3.

There isn't any way to address this in TLS 1.3 since it isn't a fault in TLS 1.3. If you have one or more RSA keys for which a valid certificate exists associating them to some name, and one or more of those RSA keys is used on a service vulnerable to a Bleichenbacher Oracle, then the attacker can use this to answer CertificateVerify for that valid certificate and impersonate the target in TLS 1.3.

Any TLS 1.3 client that doesn't accept RSA keys is immune. Any system in which servers don't use RSA keys for TLS 1.2 and earlier (or doesn't support old versions at all) is immune. A system which is somehow truly immune to the Bleichenbacher Oracle for RSA in PKCS#1v1.5 is immune.

Note that the attack is also probably not very practical in the real world because of timing, as the authors explain.