TLS Raccoon Attack: What You Need to Know
TLS has once again been hit with a vulnerability — this time in the mascot form of nature’s little bandits, the raccoon. Dubbed Raccoon Attack, this vulnerability affecting TLS 1.2 and earlier allows attackers under the right conditions to break encryption and read private communications between 2 parties. While difficult to exploit based on its need for precise timings and specific server configurations, the vulnerability is capable of breaking the Diffie-Hellman methods of communication.
In this blog, we look at how the Raccoon Attack works, who it might affect, and available patches for this TLS vulnerability.
How Does the Raccoon Attack Work?
Key exchange works by two individual parties each containing their own public key opening up a line of communication with one another. Computer A gives Computer B its public key, and Computer B does the same. Using each other’s public key, a private key is generated and used to encrypt the communications between A and B called a shared key.
Raccoon works by having all leading zero bytes in the premaster secret stripped before being used in further computations. Because the resulting premaster secret is used as input for the key derivation function, precise timing may enable attackers to create what’s called an Oracle from the TLS server. An Oracle tells the attacker whether a premaster secret starts with a 0 or not.
While learning one byte is not particularly useful to an attacker, if they can intercept a message with the value of Computer A’s public key, the attacker can build values related to the public key and send them to the server using distinct TLS handshakes. The following example is taken from raccoon-attack.com:
CVE Designations and Patches
Thankfully, vendors involved at this point have already taken action to fix this exploit.
F5 obtained the CVE number CVE-2020-5929 and recommends customers to patch products or to force using fresh ephemeral keys. The official F5 security advisory can be found here.
OpenSSL assigned the CVE CVE-2020-1968 and has pointed out that since version 1.0.2f uses fresh DH keys and thus the attack mainly affects 1.0.2 when DH certificates are in use. OpenSSL’s security advisory can be found here.
Mozilla assigned the CVE CVE-2020-12413 and solved this exploit by disabling DH and DHE cipher suites in Firefox which they were already planning on doing before this attack.
Microsoft assigned CVE-2020-1596 and has their Security Response located here.
Are You Impacted?
To see if you’re vulnerable, you can go to https://www.ssllabs.com/ssltest/ and if “DH public server param (Ys) reuse” says “yes” then you are vulnerable. Raccoon-attack.com will also be coming out with their own test in the near future.
Firefox is the last browser to support DH(E) cipher suites and took them out starting with Firefox 78 in June this year. TLS 1.3 is not affected, nor does Raccoon let attackers steal the private key, so the attack must be performed for each individual connection you want attacked.
The Raccoon Attack, while complicated to execute and requiring very specific conditions to achieve, is a noteworthy vulnerability that all organizations should be concerned about patching. If you use F5, Firefox and OpenSSL, it’s advised you update to patched versions and read the security announcements for more information.
Looking for additional information on open source security? These resources are a good place to start.
- Blog - Debunking Open Source Software Security Myths
- Blog - Java Security Update: OpenJDK Vulnerabilities You Need to Know
- Blog - EnterpriseDB vs. Postgres: Availability, DR, Security, and Performance
- Webinar - Why Security-Hardened CentOS Matters
Is Your Open Source Implementation Secure?
With guidance from our open source experts, you can rest assured that your team is following accepted best practices for enterprise open source security. Talk to an expert today to see how OpenLogic can help.