It’s that time again. As protocols mature, inevitably security vulnerabilities lurking beneath the surface are uncovered by security professionals. The so-called “Racoon” vulnerability is unusual however in that it affects TLS 1.2, arguably the most secure version of SSL/TLS to be using today. Some sensationalists describe this as the “Heartbleed of 2020”, while other researchers contend that this vulnerability isn’t much more than theoretical. Like most things, the truth is somewhere in the middle.
Analyzing the attack vector
Whenever we see a new SSL/TLS vulnerability, the first question we must ask is always the same: Is this a protocol vulnerability, or an implementation vulnerability? Protocol vulnerabilities are much, much more severe. They are a lapse in strategy, and require protocol revisions to an RFC or a new protocol version entirely. Implementation flaws on the other hand are less dangerous. They might affect only a single library (such as OpenSSL) or be widespread across many implementations of SSL/TLS. In the case of the Racoon attack, it is very much in the latter camp. Reuse of public Diffie-Hellman parameters allow for sophisticated “timing-based” attacks, not unlike the Spectre vulnerability which plagued Intel processors in 2018.
Timing attacks exploit predictable differences in how long a server takes to respond.
What exactly does Racoon exploit? As we know, SSL/TLS combines asymmetric and symmetric cryptography in order to realize the best qualities of both. A public key (signed by a trusted third party) uniquely identifies a server. Communication sent to it can only be decrypted by the corresponding, intrinsically linked public key. While we could continue to follow this pattern for the duration of communication, it would be extremely slow. In order to improve performance a symmetric key is agreed upon over the asymmetric channel. That symmetric key can be static, or it can be “rolling” (change throughout the course of the communication).
What’s the risk?
These “rolling” symmetric keys are accomplished via a protocol called “Diffie-Hellman” which is a key-exchange protocol used to agree upon a symmetric key. These special rolling keys provide a property referred to as “Perfect Forward Secrecy”, and are appealing because even if an attacker compromises the private key used to anchor the communication at a later point in time, (and captured encrypted traffic in the past) they still cannot decrypt the contents. In TLS 1.2 and earlier, whether a session uses PFS is a facet of the agreed upon “Cipher” – a pluggable rules engine for which encryption primitives and implementations will actually be used.
An “cryptographic primitive” is one of the building blocks from which practical applications are built. These include things like one-way hash functions.
As of TLS 1.3, all communication uses PFS (but does not allow for the reuse of ephemeral keys, which is why it is not affected by Racoon). Racoon exploit’s the reuse of ephemeral keys in this rolling key exchange to deduce the symmetric key. It’s notably only possible for servers whose configuration either uses a static key for Diffie-Hellman or reuses DH public keys.
Ultimately, it has been a recommendation for many years to disable “DH” ciphers in favor of “DHE” ciphers (Diffie-Hellman Ephemeral, meaning non-static keys). Unfortunately, the story does not quite end there. Even if a static key is not used, sometimes ephemeral keys are periodically reused. This too is no longer considered a secure practice. As of OpenSSL 1.0.2f, anything built against OpenSSL will generate single-use DHE keys by default. Unfortunately, on Windows Servers, IIS reuses DH params (though for a short enough duration that exploitation is exceptionally unlikely). On these servers TLS 1.3 should be preferred.
How do I know if I’m affected?
SSL Labs provides a powerful suite of tools for scanning the security of your site’s implementation. www.ssllabs.com/ssltest. In this case, the action item to look for is “DH public server param (Ys) reuse”
In the screenshot above, the server is NOT vulnerable to Racoon. If your results look like this, you are not affected by the Racoon attack.
If however, your server does reuse the DH server params, your best bet to stay secure is to disable any DH or DHE ciphers. (ECDHE can still safely provide your clients with perfect forward secrecy!)
Examples of ciphers to remove include:
DHE-RSA-AES128-SHA256 DHE-RSA-AES256-SHA256 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES256-GCM-SHA384 DHE-RSA-CHACHA20-POLY1305
All in all, Racoon is not a particularly big concern for most businesses. Anyone following best practices likely already is not using static DH ciphers. Many organizations are starting to implement TLS 1.3 as an option, mitigating any risk posed by Racoon, at least for clients that support it.