Researchers have identified a new form of denial-of-service (DoS) attack, termed the D(HE)at attack, which leverages the high computational requirements of the Diffie-Hellman key exchange protocol, particularly its ephemeral variant (DHE), to exhaust server resources with minimal effort from the attacker.
This attack is named for its potential to overburden the CPU by forcing the victim to perform the computationally intensive process of modular exponentiation, a key component of the Diffie-Hellman key exchange used in cryptographic protocols like TLS, SSH, IPsec, and OpenVPN.
Here’s an in-depth explanation of how this attack operates and its potential consequences.
Understanding the D(HE)at Attack
The Diffie-Hellman key exchange is commonly employed to securely exchange cryptographic keys over public networks.
Under normal conditions, both the client and server engage in similar operations, such as generating public keys and calculating shared secrets, which involve resource-heavy modular exponentiation. In theory, this ensures that both parties share the computational load evenly.
However, the D(HE)at attack exploits a weakness in older versions of protocols like TLS (Transport Layer Security) prior to version 1.3. In these versions, an attacker can initiate a handshake by claiming to support only the ephemeral version of Diffie-Hellman.
This forces the server to perform the computationally intensive task of generating a public key, without the attacker having to perform any reciprocal computation.
After the server completes the process, the attacker abruptly ends the connection, leaving the server to bear the entire computational burden.
Exploiting Weaknesses in Protocols and Implementations
In protocols like TLS 1.3 or SSH, the client is required to send its public key. However, a malicious client can send an arbitrary value as its public key, avoiding the need to perform modular exponentiation.
The server, unaware of the deception, proceeds to calculate the shared secret, performing another round of modular exponentiation. Even though the key exchange eventually fails, the server has already expended a significant amount of computational resources.
According to reports, several factors exacerbate the impact of this attack:
- Exponent Lengths: Some cryptographic libraries use long exponents, resulting in more costly calculations (CVE-2022-40735). The resource demands for modular exponentiation increase non-linearly with the size of these parameters, making larger key sizes particularly vulnerable.
- Public Key Validation: Servers should validate the order of the peer’s public key to prevent small subgroup confinement attacks. However, some libraries validate this regardless of whether a safe-prime group is used, leading to unnecessary computational effort (CVE-2024-41996).
- Parameter Sizes: Larger parameter sizes, such as ffdhe6144 or ffdhe8192, can significantly amplify the attack’s impact. Some libraries, like OpenSSL, default to the largest available parameter size, which can be exploited if not properly configured by servers.
The D(HE)at attack is not just a vulnerability in cryptographic library implementations that can be patched; it’s a protocol-level issue that demands a strategic approach to mitigation. Servers cannot easily distinguish between a legitimate modular exponentiation result and a random number, as there is no requirement for the client to prove any work.
Researchers have also published a FAQ addressing key questions about the D(HE)at attack.
Mitigating the D(HE)at Attack
To reduce the risk of a D(HE)at attack, organizations should consider:
- Updating Protocols: Moving to newer protocol versions like TLS 1.3, which require mutual public key exchange before the server performs any computations.
- Configuring Libraries: Tweaking cryptographic library settings to use shorter exponents and smaller parameter sizes where feasible.
- Implementing Rate Limiting: Limiting 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 signal an ongoing attack.
