Executive Summary
What is it?
D(HE)at attack (CVE-2002-20001) exploits a 20-years-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 one cannot fix it 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 the modification of 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 a potential client/server or cryptographic library implementation flaws (CVE-2022-40735), where poorly chosen key agreement parameters (private keys size) 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 which is affected by one or both issue an attacker may able to exploit the vulnerabilities together making D(HE)at attack particularly effective.
Who is vulnerable?
D(HE)at attack (CVE-2002-20001) is a flaw in any cryptographic protocol, that can initiates Diffie-Hellman key agreement during the handshake. It means that any network services that use a cryptographic protocol – such as IKE, OpenVPN, SSH, TLS – is affected by the weakness, however, several circumstances affect the efficiency of an attack.
There are some cryptographic protocols in which the attack are 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, however there can be mitigation techniques even if it should be enabled for whatever reason.