“Raccoon Attack” Targets TLS 1.2 and Earlier, but Is Difficult to Exploit

This blog originally appeared on SSL.com with the title "Racoon Attack" Targets TLS 1.2 and Earlier, but is Difficult to Exploit

Author: Connor Wilson

There’s a new type of SSL/TLS attack in town. A team of academic security researchers recently released a paper introducing the Raccoon attack. Raccoon is a timing vulnerability in the TLS specification which impacts HTTPS and other services reliant on SSL/TLS. Under very specific and rare conditions, Raccoon allows malicious third-party attackers to break SSL/TLS encryption and read sensitive communications.

Specifically, Raccoon attacks take place on Diffie-Hellman key exchanges. When both TLS peers exchange public keys as part of a Diffie-Hellman exchange, they then compute a shared key called the “premaster secret,” which is then used to derive all TLS session keys with a specific key derivation function.

TLS 1.2 and all preceding versions require that all leading zero bytes in this premaster secret be stripped before proceeding. The resulting premaster secret is used as an input in the key derivation function, which is based on hash functions with different timing profiles. These precise timing measurements could allow an attacker to construct an oracle from the TLS server, which would tell the attacker whether or not a computed premaster secret starts with zero.

From this single byte, attackers can begin to construct a set of equations to compute the original premaster secret established between the client and server. This could allow attackers to decrypt communication between users and the server, including usernames, passwords, credit card information, emails, and a long list of potentially sensitive information.

While it sounds terrifying, keep in mind that this attack can only take place under very specific and rare circumstances: the server must reuse public Diffie-Hellman keys in the handshake (already considered bad practice), and the attacker must be able to make precise timing measurements. Furthermore, the browser must support the vulnerable cipher suites (as of June 2020 all the major browsers have dropped them).

Even if Raccoon is not practical for most attackers, there are still steps website owners can take to protect themselves and visitors:

TLS 1.3 is not vulnerable to the Raccoon attack. If you’re sure that most or all of your website’s visitors use modern, TLS 1.3 compatible browsers, you can simply disable TLS 1.2.

Check to make sure that your web server does not reuse public Diffie-Hellman keys. As mentioned above, this is already considered a bad practice. You can check for this with Qualsys SSL Labs’ SSL Server Test. In the results for your website, you’ll want to see a value of “No” for “DH public server param (Ys) reuse.”:

If this value is “Yes,” check the documentation for your server and make sure that your server is properly configured to provide forward secrecy, also known as “perfect forward secrecy,” which will preclude the reuse of public DH keys. (Please check out this guide to SSL/TLS best practices for more information on forward secrecy.)

About the Author: Connor Wilson is a content writer for SSL.com, a certificate authority based out of Houston, Texas