Frequently Asked Questions

Who is vulnerable?

In theory, all protocols that use the Diffie-Hellman algorithm for key exchange are affected. In practice, there are differences between the particular cryptographic protocols and their implementations, making one more affected than others.

The proof-of-concept implementation of the attack supports the following protocols,

however, other protocols such as IPsec (IKEv1, IKEv2) must also be affected.

Is my server vulnerable?

It depends on your server configuration. If your server offers the Diffie-Hellman key exchange, then you are affected. However, the effectiveness of a potential attack largely depends on the specifics of the cryptographic protocol, the library implementation, and the key size used during the key exchange. You can use either some free software (e.g., CryptoLyzer, SSLyze, ssh-audit, testssl.sh), and some SaaS solutions (e.g., Scanigma) as well to check whether your server offers Diffie-Hellman key exchange and if so, under what parameters.

How practical is the attack?

It depends on hardware capabilities and the server configuration. If your server offers Diffie-Hellman key exchange with larger key sizes and the cryptographic library you use affected by the “long exponent” issue only an attacker need to send extremely low amount of request to cause 100% CPU load on the server. For the exact number of requests needed to overload a server see the attack scenario section of the full technical paper about the attack. For testing your server you can use the proof-of-concept implementation D(HE)ater.

Can I detect if someone has exploited this against me?

Yes, you can, though it may require some configuration changes. An application server can log instances where a client connection is interrupted during cryptographic handshakes. While this can happen under normal circumstances, it is also indicative of suspicious behavior. A high number of log messages about connections being lost during the handshake phase likely suggests an attack. For more details see mitigations page.

Should I disable Diffie-Hellman in my server configurations?

Not necessarily. However, you need to check both server configuration and cryptographic library implementation details. The former is the simpler as the mentioned free software can be used the check whether your server configuration enables the Diffie-Hellman key exchange or not and if so what key sizes are offered. The latter is harder is as there is no obvious way to check the performance of the Diffie-Hellman implementation and used exponent sizes in the case of a cryptographic library. For the details of the most popular libraries of this point of view see the analysis section of the full technical paper about the attack.

Why is the attack called “D(HE)at”?

The attack is named for its ability to overheat the CPU by making the victim execute the CPU-intensive operation of [modular exponentiation used in the Diffie-Hellman key exchange within various cryptographic protocols (e.g., TLS, SSH, IPsec, OpenVPN, etc.).

Is this vulnerability serious enough to deserve a web page?

D(HE)at is not an issue with a client, server implementations, or a cryptographic library flaw, so it cannot be fixed by simply installing a software update. Instead, it exploits the Diffie-Hellman key agreement protocol, meaning that it may affect many the cryptographic protocols (e.g., TLS, SSH, OpenVPN, IKEv1/IKEv2, …) use the ephemeral version of the Diffie-Hellman for exchanging keys. Therefore, a comprehensive solution to this vulnerability would require modifying the cryptographic protocols that use DHE key agreement, as well as the client/server or library implementations.

Are there implementations more vulnerable than others?

Yes, some implementation flaws can seriously affect the effectiveness of the D(HE)at attack.

Long exponent (CVE-2022-40735)

Implementations may use unnecessarily long exponents ( CVE-2022-40735) which makes the modular exponentiation – the CPU-intensive operation of the Diffie-Hellman key exchange – significantly more expensive than it should be.

Library Affected Versions
OpenSSL (1.x) \(\le 1.1.1\)
OpenSSL (3.x) \(\le 3.0.5\)
Mbed TLS
OpenJDK \(\le 17.0.5\)
Oracle JDK \(\le 17.0.5\)

Unnecessary validation (CVE-2024-41996)

Implementations may perform public key validation against small subgroup confinement attack unnecessarily (CVE-2024-41996), where the validation is as expensive as public key generation using large exponents.

Library Affected Versions
OpenSSL (1.x) n/a\(^*\)
OpenSSL (3.x) \(\ge 3.0\)

* no public key validation

Large key size by default

The flaws mentioned earlier are coupled with large key sizes enabled by default makes the application uses the library particularly vulnerable to the D(HE)at attack in the absence of mitigation techniques.

Library Key Size
OpenSSL (1.x) n/a\(^*\)
OpenSSL (3.x) 8192
OpenJDK 8192
Oracle JDK 8192

* no finite field Diffie-Hellman parameter negotiation support

How can I contact you?

You can reach us via Twitter, or LinkedIn: