D(HE)at Attack – 20-Yr-old Flaw Let Attackers Exploit Diffie-Hellman Protocol To Over-Heat Your CPU

Researchers uncovered a new type of denial-of-service (DoS) attack, known as the D(HE)at attack, exploits the computational demands of the Diffie-Hellman key agreement protocol, particularly its ephemeral variant (DHE), to overwhelm servers with minimal effort from the attacker.

The attack is named for its ability to overheat the CPU by making the victim perform the heavy computation of modular exponentiation, which is used in the Diffie-Hellman key exchange within cryptographic protocols like TLS, SSH, IPsec, and OpenVPN.

Here’s a detailed look at how this attack works and its implications.

How Does D(HE)at Attack Works

The Diffie-Hellman key agreement protocol is widely used to exchange cryptographic keys securely over public channels.

Under normal circumstances, the client and server perform similar operations, including public key generation and shared secret calculation, which involves computationally intensive modular exponentiation. Theoretically, this means both parties share the computational burden equally.

However, the D(HE)at attack takes advantage of a protocol flaw, particularly in older versions of protocols like TLS (Transport Layer Security) prior to version 1.3. In these versions, a malicious client can initiate a handshake by pretending to support only the ephemeral variant of Diffie-Hellman.

This forces the server to generate a public key without the client having to reciprocate with its own computational effort.

Once the server completes this task, the attacker terminates the connection, leaving the server to bear the computational cost.

Exploiting Protocol and Implementation Weaknesses

The client must send its public key in protocols like TLS 1.3 or SSH. However, a malicious client can send an arbitrary number as its public key, avoiding the need for modular exponentiation.

Unaware of this deception, the server calculates the shared secret, performing a second modular exponentiation. Although the key agreement eventually fails, the server has already expended significant computational resources.

According to the report, Certain implementation flaws and protocol configurations exacerbate the attack:

1. Exponent Lengths: Some cryptographic libraries use long exponents, leading to more expensive calculations (CVE-2022-40735). The resource requirement for modular exponentiation grows non-linearly with the size of these parameters, making larger key sizes particularly vulnerable.
2. Public Key Validation: To prevent small subgroup confinement attacks, servers should validate the order of the peer’s public key. However, some libraries perform this validation regardless of whether a safe-prime group is used, triggering unnecessary computational effort (CVE-2024-41996).
3. Parameter Sizes: Larger parameter sizes, such as ffdhe6144 or ffdhe8192, can significantly increase the attack’s impact. Some libraries, like OpenSSL, default to the largest available parameter size, which can be exploited if not properly configured by application servers.

The D(HE)at attack is not merely a flaw in cryptographic library implementations that can be patched with a software update.

It is a protocol-level vulnerability that requires a more strategic approach to mitigation. Servers cannot easily distinguish between a legitimate modular exponentiation result and a random number, as there is no proof-of-work required from the client.

Researchers also released an FAQ detailing some of the most relevant questions about D(HE)at attack.

D(HE)at Attack Mitigation

To mitigate the risk of a D(HE)at attack, organizations should consider:

• Updating Protocols: Transitioning to newer protocol versions like TLS 1.3, which require mutual public key exchange before server-side computations.
• Configuring Libraries: Adjusting cryptographic library settings to use shorter exponents and smaller parameter sizes where possible.
• Implementing Rate Limiting: Applying rate limits to the number of handshake requests a server processes from a single client.
• Monitoring and Alerts: Setting up monitoring systems to detect unusual patterns of handshake requests that could indicate an ongoing attack.