What is it?

The D(HE)at attack (CVE-2002-20001) exploits a 20-year-old flaw in the finite field Diffie-Hellman key agreement protocol (DHE) that allows remote users without any privileges to trigger expensive server-side calculations without any significant resource (CPU) requirement, posing a threat of a denial-of-service (DoS) attack.

How bad is it?

D(HE)at is not a client, server implementation, or cryptographic library flaw, so it cannot be fixed by installing a simple software update. Instead, it exploits the Diffie-Hellman key agreement protocol, meaning that a comprehensive solution to the vulnerability would require modifying the cryptographic protocols using the DHE key agreement and the client/server or library implementations as well.

However, it is crucial to note that the attack poses a threat only to availability; it does not impact confidentiality, integrity, or scope. The CVE-2002-20001 vulnerability has a base score of 7.5 (CVSS 3.1), signifying high severity – the highest achievable by a DoS attack – but falling short of critical.

Additionally, there are potential client/server or cryptographic library implementation flaws (CVE-2022-40735), where poorly chosen key agreement parameters (private key sizes) are used, deviating from the values recommended by NIST, or public key validation is performed when it is unnecessary (CVE-2024-41996) according to NIST. These flaws make the already expensive Diffie-Hellman key exchange even more expensive. If a server application uses a cryptographic library that is affected by one or both issues, an attacker may be able to exploit the vulnerabilities together, making the D(HE)at attack particularly effective.

Who is vulnerable?

The D(HE)at attack (CVE-2002-20001) is a flaw in any cryptographic protocol that can initiate Diffie-Hellman key agreement during the handshake. This means that any network services that use a cryptographic protocol – such as IKE, OpenVPN, SSH, TLS – are affected by the weakness, though several circumstances affect the efficiency of an attack.

There are some cryptographic protocols in which the attack is more efficient (e.g., TLS 1.3), while others (e.g., earlier TLS versions, SSH) are less efficient, but the differences are not significant. The effectiveness of the D(HE)at attack is much more affected by the default configurations of the application servers and the implementation details of the cryptographic libraries.

How to mitigate?

The simplest solution is to disable Diffie-Hellman key exchange in the server configurations, though there can be mitigation techniques even if it should be enabled for whatever reason.