Mitigations

Theory

Decreasing the Diffie-Hellman key size can only partially mitigate the attack. Currently, Diffie-Hellman keys larger than 2048 bits are considered secure. The 2048-bit key size is the most widespread for earlier TLS versions, and it is not advisable to recommend using a smaller key size, even though the attack can still be effective with a 2048-bit key. Additionally, some protocols allow negotiation of the key size, so a malicious client can force the use of a 4096- or 8192-bit key, which may increase CPU computation and the attack’s effectiveness. The situation is similar for SSH, IPsec, and TLS 1.3.

Applying proof-of-work (POW) systems can also help mitigate this issue in cryptographic protocols. In this approach, servers may require clients to solve a mathematical puzzle before proceeding with the cryptographic handshake, especially when a denial-of-service attack is suspected. These puzzles are designed to be easy for legitimate clients but computationally expensive for attackers attempting to initiate many connections at once. The Client Puzzle Protocol (CPP) is one example of this concept in practice.

Protocol Independent

Has this issue been addressed in the relevant RFCs?

Unfortunately, no, or only partially. Some cryptographic protocols, such as IKE, use cookies—random values generated by the server that the client must return. This mechanism is intended to prevent clients from precomputing handshake messages, forcing them to generate each message for every connection attempt. While this approach is theoretically effective, in practice it does not sufficiently reduce the attack’s efficiency.

Are application servers taking steps to address this issue?

Some application server implementations can help mitigate this attack by limiting the number of concurrent unauthenticated connections. For example, OpenSSH and Tectia SSH provide options to restrict the number of simultaneous unauthenticated sessions, which can reduce the attack’s effectiveness.

For more information on configuring servers and the impact of these settings, refer to the DHEater GitLab page.

Protocol Dependent

TLS

Can client certificate authentication prevent this attack?

No, it cannot. The server performs the computationally expensive Diffie-Hellman key exchange before sending a client certificate request. This means that even if client certificate authentication occurs later in the handshake, an attacker can still force the server to perform the intensive computation.

Can the latest protocol version prevent this attack?

The answer is nuanced. While TLS 1.3 incorporates Diffie-Hellman key exchange, it introduces a supported groups mechanism that allows clients to select the key size—a change from earlier TLS versions (<1.2), where servers controlled this parameter. Both TLS 1.3 and TLS 1.2 (via extension) support key size negotiation during the cryptographic handshake. This allows malicious clients to compel servers to use the maximum configured key size, potentially amplifying the attack’s effectiveness. Notably, OpenSSL only supports key size negotiation in TLS 1.3 starting from version 3.0, while other libraries like GnuTLS may implement this feature in TLS 1.2 as well (RFC 7919).

SSH

Can strong authentication prevent this attack?

No, strong authentication does not provide protection. The server performs the computationally expensive Diffie-Hellman key exchange before requesting a client certificate. This means an attacker can force the server to perform the intensive computation regardless of whether client certificate authentication occurs later in the handshake process.

Can rate limiting of unauthenticated sessions prevent this?

Yes, rate limiting unauthenticated sessions can help mitigate this attack. By limiting the number of new SSH connections or key exchange attempts from a single source, the impact can be reduced. However, this may not completely prevent the attack, especially if the attacker uses multiple sources or distributed methods.

Configuration

Diffie-Hellman (DHE) key exchange should be disabled if no other mitigation mechanism can be used and either elliptic-curve variant of Diffie-Hellman (ECDHE) or RSA key exchange is supported by the clients. The fact that RSA key exchange is not forward-secret should be considered.

TLS

Elliptic-curve (named group) settings are necessary only if the underlying cryptographic library supports negotiation of Diffie-Hellman groups by implementing RFC7919 in TLS 1.2 or supporting the Finite Field Diffie-Hellman parameter groups named groups in TLS 1.3.

Library	Version	FFDHE groups in TLS 1.2	FFDHE groups in TLS 1.3
OpenSSL	< 3.0	no	no
OpenSSL	≥ 3.0	no	yes
GnuTLS	≥ 3.5.6	yes	no
GnuTLS	≥ 3.6.3	yes	yes

Apache

SSLCipherSuite ...:!kDHE
SSLOpenSSLConfCmd Groups x25519:secp256r1:x448

NGINX

ssl_ciphers ...:!kDHE;
ssl_ecdh_curve x25519:secp256r1:x448;

Postfix

Diffie-Hellman key exchange algorithms can be removed by setting the tls_medium_cipherlist configuration option.
```
tls_medium_cipherlist ...:!kDHE
```
The maximum number of new TLS sessions that a remote SMTP client is allowed to negotiate can be controlled by the smtpd_client_new_tls_session_rate_limit configuration option.
```
smtpd_client_new_tls_session_rate_limit 100
```

Others

See moz://a SSL Configuration Generator for configuration syntax.

DH parameter files

If DH key exchange needs to be supported, the recommended private key length value should be set to ensure the best performance of DH key exchange. This option value should be set appropriately to achieve the best performance without security risk.

You can check whether your DH parameter file contains the recommended private key value by using the following command:

dh_param_priv_key_size_setter /path/to/dh/parameter/file.pem

The result looks like the following. If the original private key size is None, some cryptographic libraries use the public size for the private key size unless the application server overrides this behavior. This will cause much lower performance than if small private keys were used.

Original private key size: None
Set private key size: None
-----BEGIN DH PARAMETERS-----
MIIBCAKCAQEA//////////+t+FRYortKmq/cViAnPTzx2LnFg84tNpWp4TZBFGQz
+8yTnc4kmz75fS/jY2MMddj2gbICrsRhetPfHtXV/WVhJDP1H18GbtCFY2VVPe0a
87VXE15/V8k1mE8McODmi3fipona8+/och3xWKE2rec1MKzKT0g6eXq8CrGCsyT7
YdEIqUuyyOP7uWrat2DX9GgdT0Kj3jlN9K5W7edjcrsZCwenyO4KbXCeAvzhzffi
7MA0BM0oNC9hkXL+nOmFg/+OTxIy7vKBg8P+OxtMb61zO7X8vC7CIAXFjvGDfRaD
ssbzSibBsu/6iGtCOGEoXJf//////////wIBAg==
-----END DH PARAMETERS-----

To set the recommended private key size in a DH parameter file, use the following command:

dh_param_priv_key_size_setter --private-key-size KEY_SIZE /path/to/dh/parameter/file.pem

For appropriate private key sizes, see Table 2 of NIST SP 800-57 Part 1. Alternatively, you can download the well-known DH parameters where the recommended private key size is set according to OpenSSL default values from the data directory.

SSH

OpenSSH

Diffie-Hellman key exchange algorithms can be removed by setting the KexAlgorithms configuration option.

KexAlgorithms -diffie-hellman-group1-sha1,diffie-hellman-group1-sha256,diffie-hellman-group14-sha1,diffie-hellman-group14-sha256,diffie-hellman-group15-sha256,diffie-hellman-group15-sha512,diffie-hellman-group16-sha256,diffie-hellman-group16-sha512,diffie-hellman-group17-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha512

The maximum number of concurrent unauthenticated connections can be controlled by several configuration options:
- MaxStartups (globally)
```
MaxStartups 10:30:100
```
- PerSourceMaxStartups (per source IP subnetworks)
```
PerSourceMaxStartups 1
```
- PerSourceNetBlockSize (size of the subnetworks grouped together)
```
PerSourceNetBlockSize 32:128
```

VPN

OpenVPN

Diffie-Hellman key exchange algorithms can be removed in TLS versions prior to 1.2 by setting the tls-cipher configuration option.
- Using OpenSSL
```
tls-cipher ...:!kDHE
```
- Using mbed TLS, any cipher suites containing DHE should be removed
Finite field Diffie-Hellman groups can be removed in TLS version 1.3 by setting the tls-groups configuration option.
```
tls-groups x25519:secp256r1:x448
```
The control channel can be authenticated and/or encrypted by setting the tls-auth, tls-crypt, tls-crypt-v2 configuration options.
```
tls-auth file
tls-crypt file
tls-crypt-v2 file
```

IPsec

StrongSwan

Diffie-Hellman key exchange algorithms can be removed by setting the ike configuration option explicitly and not using key exchange algorithms whose names start with modp.
The maximum number of unauthenticated connections can be controlled by several configuration options:
- cookie_threshold (activate cookie mechanism)
```
cookie_threshold 10
```
- block_threshold (activate block mechanism)
```
block_threshold 5
```

Fail2Ban

Be aware that attacks can originate from large private networks with hundreds or thousands of devices. If such a network uses network address translation (NAT), the attacked service can only block the network’s public IP address. Blocking this address will prevent all devices behind that NAT from accessing your public service (such as a website). However, this is not a complete solution—if the attacker controls a sufficiently large botnet with many different IP addresses, they can continue the attack despite IP bans.

Nonetheless, temporarily banning the IP address from which a private service’s vulnerability is being exploited poses minimal risk.

TLS

Apache

There are no relevant filters.

apache-ssl.conf in the fail2ban directory should be copied to the filter.d directory under the fail2ban configuration directory.
The following should be added to the jail.local file in the fail2ban configuration directory:
```
[apache-ssl]
port    = https
logpath = %(apache_error_log)s
maxretry = 1
```

Postfix

There is a relevant filter, but it is applied only in DDoS mode. The following should be added to jail.local:

[postfix]
mode = ddos

Dovecot

There is a relevant filter, but it is applied only in DDoS mode. The following should be added to jail.local:

[dovecot]
mode = aggressive

or a specific filter can be used without changing the mode of Dovecot.

dovecot-ssl.conf in the fail2ban directory should be copied to the filter.d directory under the fail2ban configuration directory.

The following should be added to jail.local in the fail2ban configuration directory:

[dovecot-ssl]
port    = pop3,pop3s,imap,imaps,submission,465,sieve
logpath = %(dovecot_log)s
backend = %(dovecot_backend)s
maxretry = 1

SSH

OpenSSH

There is a relevant filter, but it is applied only in DDoS mode. The following should be added to jail.local:

[sshd]
mode = ddos