In unserem Blog veröffentlichen wir in unregelmäßigen Abständen Artikel zu verschiedenen Themen der IT-Sicherheit, wie z.B. Open Penetrationstests, öffentlichen Bedrohungsanalysen und Analysen zu anderen interessanten Themen.

In September, we* published our new attack called Raccoon. Raccoon is a timing vulnerability that affects all TLS specifications up to 1.2. It allows attackers under certain conditions to break the encryption and read sensitive communication, for example, HTTP traffic or emails. Luckily, the vulnerability is really hard to exploit and relies on very precise timing measurements and on a specific server configuration to be exploitable. 

Attack Overview

The attack targets the Diffie-Hellman (DH) key exchange which is a well-established method for exchanging keys in every communication protocol, including TLS. When using Diffie-Hellman, both TLS peers generate private keys at random (a and b) and compute their public keys: ga mod p and gb mod p. These public keys are sent in the TLS KeyExchange messages. Once the public keys are exchanged, both the client and server can compute a shared key gab mod p - called premaster secret - which is used to derive all TLS session keys with a specific key derivation function.

Raccoon exploits a tiny side channel in the TLS specification; TLS 1.2 (and all previous versions) prescribes that all leading zero bytes in the premaster secret are stripped before used in further computations. This seems to be not a big deal but the resulting premaster secret is used as an input into a hash function with different timing profiles for different secret lengths. An attacker can use such processing to determine whether the resulting premaster secret starts with zero or not. If the server repeats its DH public keys, the attacker can target one client-server connection. The attacker then attempts to find several premaster secrets starting with zero, which are related to the original DH public keys. After collecting enough secrets, the attacker is able to use a Hidden Number Problem solver to compute the original premaster secret and thus decrypt the original connection [1].

2020 09 raccoon attack

Figure 1: Overview of the Raccoon attack.

Small Practical Impact on TLS

The DH key exchange is a widely used technique to exchange shared keys. Therefore, one would think that this attack affects many TLS servers. Luckily, this is not the case because the attack relies on the fact that the connection is established with a cipher suite using DH over finite fields and the server repeats DH public keys. This was indeed quite typical about >5 years ago. However, nowadays most of the connections use a DH key exchange over elliptic curves. Even if a DH key exchange over finite fields is used, the server typically uses fresh ephemeral public keys.

The DH handshake over elliptic curves is preferred because of its performance and security advantages. For example, Firefox 78 was the last major browser which decided to remove DH over finite fields.

Ok, So Is There Nothing That I Should Do as a TLS Admin?

There is one minor exception regarding the attack impact; if you are using an F5 appliance vulnerable to this attack (CVE-2020-5929), you should update your server or your configuration. The reason is that a specific bug in this appliance reveals the first premaster secret zero byte without complex timing measurements. The DH public values are repeated per default. This makes the attack much stronger. See F5 Security Advisory.

If you are using an up-to-date server, your configuration should be secure. If you want to be sure, you can also use our freshly-released TLS-Scanner to evaluate your server. Get the latest version of TLS-Scanner here.

Our tool evaluates whether the server is vulnerable to a direct raccoon attack (such as F5) and whether it repeats DH keys. An example output can be seen in Figure 2.

2020 11 raccoon tls scanner

Figure 2: Example output of TLS-Scanner for our DamnVulnerableOpenSSL.

So Why Is the Attack Interesting at All?

Raccoon is a new cryptographic attack showing for the first time how to practically apply a Hidden Number Problem solver on a Diffie Hellman key exchange. We believe that our attack will be extended in the future in the following ways (see also my Twitter feed here):

  • Researchers will analyze different cryptographic standards and validate whether they are vulnerable to a similar attack using DH key exchange. For example, this is highly relevant for the design of new post-quantum schemes.
  • Researchers will try to adapt the attack to the elliptic curve DH key exchange. This adaptation requires several new cryptographic techniques and new side channels leaking the first byte.
  • There will be different devices that will be vulnerable to a direct form of the Raccoon attack (as we showed for the F5 servers). This can have critical consequences, especially if the attack targets Hardware Security Modules (HSMs) or other hardware appliances.

Our attack was already included for consideration in the RFC draft for Hybrid key exchange in TLS 1.3: https://tools.ietf.org/html/draft-ietf-tls-hybrid-design-01#ref-RACCOON 

More information on the attack can be found on the attack website: https://raccoon-attack.com/

 

If you want to learn more about attacks or the security of PKCE, OAuth, OpenID Connect, and other Single Sign-On solutions, you can also book one of our in-depth Single Sign-On training courses.

 


[1] D. Boneh et al. Hardness of computing the most significant bits of secret keys in Diffie-Hellman and related schemes. CRYPTO 96. URL: https://link.springer.com/content/pdf/10.1007%2F3-540-68697-5_11.pdf.

* The attack was published by Robert Merget (Ruhr University Bochum), Marcus Brinkmann (Ruhr University Bochum), Nimrod Aviram (Tel Aviv University), Juraj Somorovsky (Paderborn University and co-founder of Hackmanit), Johannes Mittmann (Bundesamt für die Sicherheit in der Informationstechnik), and Jörg Schwenk (Ruhr University Bochum and co-founder of Hackmanit).

Raccoon logo © https://raccoon-attack.com/