Eavesdropping on TLS 1.3? It Can Happen.

By Will Harle

In March 2018 an update to TLS 1.2 aptly named TLS 1.3 was released with the final version being released in August 2018. With the release of TLS 1.3, vulnerabilities that were previously available in TLS 1.2 such as weak cipher suites (SHA-1, RC4, and DES), CVE-2016-0701, and the use of EXPORT strength ciphers on the protocol were addressed. In addition to these security vulnerabilities being patched, TLS 1.3 only took one-round trip to establish the TLS handshake leading to an increase in speed of encrypted connections. Unfortunately, in just six short months after the final version of TLS 1.3 was released, researchers were able to discover a vulnerability that could be used to attack it (the bugs that allow this attack to happen are identified as CVE-2018-12404, CVE-2018-19608, CVE-2018-16868, CVE-2018-16869 and CVE-2018-16870).

            In order to exploit this vulnerability in TLS 1.3 an attacker would first force the TLS 1.3 server to downgrade to TLS 1.2 by using an oracle padding attack combined with a man in the middle attack. Once this downgrade has been achieved, the attacker then runs a new variation of the Bleichenbacher attack exploiting a side channel leak in the cache access timing of RSA key exchanges in TLS 1.2 to obtain all 2048 bits of the RSA key in plaintext. The concept of the Bleichenbacher attack has actually been around since 1998 with several variations of the attack being created throughout the years. In fact, the original Bleichenbacher attack focused on using the error messages provided by the SSL server in the PKCS #1 v1.5 padding to create an adaptive-chosen ciphertext attack.

            As mentioned earlier, the first step in applying this version of the Bleichenbacher attack on servers using TLS 1.3 is forcing the server to downgrade to TLS 1.2. An attacker can do this by using the oracle padding attacks and the man in the middle attacks mentioned earlier to change the protocol the TLS server is advertising to TLS 1.2 and the cipher suite to RSA. Once they have done this, the attacker can then use their man in the middle attack to obtain the premaster secret and complete the TLS handshake between all parties involved in the attack. In order for an online version of this attack to work, the attacker has to grab the premaster secret before the browser closes the TLS handshake connection. Some browsers such as Google Chrome and Microsoft Edge enforce strict TLS handshake policies, making them time out after 30 seconds. This means that for the attacker, working efficiently in order to get this premaster secret within that timeframe is key. However, in order for this downgrade to be forced, the server must still support TLS 1.2. If the server does not support TLS 1.2, then there is nothing to downgrade to and the attack cannot be done.

            Now that the downgrade to TLS 1.2 has been forced, the attacker can then use that variation of the Bleichenbacher attack to obtain the full RSA key in plaintext as mentioned earlier. This variation of the Bleichenbacher attack also works on web browsers that force TLS handshakes to timeout in 30 seconds because the attack is designed to run in a parallelized manner on any number of TLS servers that are using the same public key certificate. This allows attackers to obtain the full RSA key within the required time limit and complete the TLS handshake before the connection times out.

From this point, the attacker can now passively observe your traffic and decode it at a later date. This allows them to see what you have been up to on the web while using that connection to the server. Something that is especially dangerous if during that time you had logged into any accounts as it gives the attacker your username and password along with access to any credit cards on those accounts. Unfortunately, several TLS implementations were vulnerable to this attack including OpenSSL, Amazon s2n, MbedTLS, Apple CoreTLS, Mozilla NSS, WolfSSL, and GnuTLS but BearSSL and BoringSSL were not vulnerable to the attack.

SSL LibraryVulnerableNot Vulnerable
Amazon s2nü 
Apple CoreTLSü 
Mozilla NSSü 
BearSSL ü
BoringSSL ü

Fortunately, not all hope is lost as there are several mitigations that can be implemented to prevent this attack from being effective on TLS 1.3. The first recommended mitigation is the deprecation of RSA key exchange in favor of the newer Diffe-Hellman key exchange. However, due to the amount of systems that still rely on RSA key exchanges and do not support Diffe-Hellman key exchanges, this mitigation would create a lot of issues with backwards compatibility and would not be practical to implement. Other mitigations involving RSA include modifying the RSA key exchange process to have separate certificates including a dedicated public key for signing or using larger RSA keys and adding speed limitations to RSA decryptions to make man in the middle attacks less practical.

There are also mitigations that can be done on the TLS side to prevent this attack from occurring including not allowing TLS servers to use the same keys across different TLS versions and ensuring that each TLS server has a different public key (if multiple TLS servers are used). Another aspect of TLS that can be modified to prevent this attack from happening is shortening the amount of time it takes for the TLS handshakes to timeout and add resistance to attacks that attempt to lengthen the period of time a TLS handshake can remain open.

            Lastly, there are mitigations that can be made to prevent this attack that focus less on TLS and RSA side of things and instead focus on the actual implementation of the protocol. These include using constant-time code and safe APIs that do not use branching or memory accesses that rely on plaintext and instead rely on an expected plaintext size to increase the length of time needed to attack these side channels. Another mitigation that could be implemented to stop this attack is using dedicated hardware for sensitive cryptographic code to stop sensitive processes from running on shared hardware like private key decryption.

            In conclusion, the use of a downgrade attack on TLS 1.3 to TLS 1.2 and then breaking it with a modified Bleichenbacher attack is a real threat that should not be ignored. All of the current web browsers today are currently using TLS 1.3 and every user is at risk of falling victim to this vulnerability. While the attack itself is not very practical and requires a significant amount of skill to complete successfully, the consequences of that attack succeeding can be very costly for whichever individual or business it succeeds on. As time goes on, this attack will only become more and more practical as different attackers continue to make their own modifications to the Bleichenbacher attack and the resources available for commercial use in computers become more powerful.


  1. https://kinsta.com/blog/tls-1-3/
  2. https://eprint.iacr.org/2018/1173.pdf
  3. https://www.zdnet.com/article/new-tls-encryption-busting-attack-also-impacts-the-newer-tls-1-3/
  4. https://robotattack.org/
  5. https://www.scmagazineuk.com/tls-13-vulnerability-enables-hackers-eavesdrop-encrypted-traffic/article/1525916
  6. https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2019/february/downgrade-attack-on-tls-1.3-and-vulnerabilities-in-major-tls-libraries/
  7. https://web-in-security.blogspot.com/2018/08/practical-bleichenbacher-attacks-on-ipsec-ike.html
  8. https://ritcsec.files.wordpress.com/2020/04/0a6a0-attackikev1.png
  9. https://www.nccgroup.trust/globalassets/newsroom/us/blog/images/2019/february/tls13signatures.png

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s