David Wong, Security Consultant, at NCC Group, a global expert in cyber security and risk mitigation, revealed details about the new cryptographic attack, last week, that can break the encrypted TLS traffic. Wong collaborated with other security researchers and found out that out of the nine different TLS implementations against cache attacks, seven were found to be vulnerable, namely, OpenSSL, Amazon s2n, MbedTLS, Apple CoreTLS, Mozilla NSS, WolfSSL, and GnuTLS.
TLS or Transport Layer Security refers to a cryptographic protocol that offers end-to-end communications security over networks. It is widely used for internet communications and online transactions. TLS (except TLS 1.3) makes use of RSA as a key exchange algorithm, which determines how the client and server will authenticate during the handshake to negotiate a shared secret. The client encrypts a shared secret under the server’s RSA public key, the server then receives it and decrypts it.
The latest attack isn’t entirely new; it is simply another variation of the original Bleichenbacher oracle attack that was able to decrypt an RSA encrypted message using the Public-Key Cryptography Standards (PKCS) #1 function.
This new attack uses a side-channel leak via cache access timings of TLS implementations to break these RSA key exchanges of TLS implementations. It affects all versions of TLS (including TLS 1.3) as well as QUIC and makes use of the state-of-the-art cache attack techniques such as Flush+Reload, Prime+Probe, Branch-Prediction, etc.
Attacking TLS 1.3 and downgrading to TLS 1.2
Since TLS 1.3 does not offer an RSA key exchange, researchers started with downgrading to an older version of TLS (TLS 1.2) for the exploitation of the attack. To downgrade a client’s connection attempt, a spoofed TLS 1.2 handshake technique is used. The server’s RSA certificate was presented in a ServerCertificate message and then the handshake was put to an end with a ‘ServerHelloDone’ message.
However, if at this point, the server does not have a trusted certificate that allows RSA key exchanges or the client refuses to support RSA key exchanges or older versions than TLS 1.2, the attack halts. Otherwise, the client will make use of the RSA public key contained in the certificate to encrypt the TLS premaster secret. It will then send it
in a ClientKeyExchange message and ends its part of the handshake using a ChangeCipherSpec and a Finished message.
It is at this time, the attack is performed to decrypt the RSA encrypted premaster secret. The last Finished message being sent should contain an authentication tag (with HMAC) of the whole transcript and should be encrypted with the transport keys derived from the premaster secret.
Now, even if some clients might have zero handshake timeouts, most serious applications such as browsers can give up on the connection attempt if the response takes too much time to arrive. So, there are several techniques that can slow down the handshake such as sending the ChangeCipherSpec message to reset the client’s timer and sending TLS warning alerts to reset the handshake timer. After the decryption attack terminates, the expected Finished message is sent to the client and a handshake is finalized.
This downgrade attack is able to bypass multiple downgrade mitigations, namely, one server-side and two client-side. TLS 1.3 servers that negotiate older versions of TLS must also advertise this information to their peers. TLS 1.3 clients that negotiate an older version of TLS must check for these values and abort the handshake if found.
On the other hand, a TLS 1.3 client that goes back to an older version of TLS must advertise this information in their subsequent client hellos. Furthermore, a client should also include the version used by the client hello inside the encrypted premaster secret.
“As it stands, RSA is the only known downgrade attack on TLS 1.3, which we are the first to successfully exploit in this research”, states Wong. The researchers also state that it is time for RSA PKCS#1 v1.5 to be deprecated and replaced by more modern schemes like OAEP (Optimal asymmetric encryption padding) and ECEIS (Elliptic Curve Integrated Encryption Scheme) for asymmetric encryption or Elliptic Curve Diffie-Hellman in case of key exchanges.
For more information, check out the official NCC Group blog.