DHEAT ATTACK

DoS attack that can be performed by enforcing the Diffie-Hellman key exchange

Who is affected?

Websites, mail servers, and other Transport Layer Security (TLS) dependent services that support Diffie-Hellman key exchange using ephemeral keys (DHE cipher suites) are at risk of the DHEat attack. Services using other cryptographic protocols can also be affected.

Secure Shell (SSH) services support Diffie-Hellman key exchange methods.
Internet Protocol Security (IPsec) services offer DH groups.
OpenVPN servers support Diffie-Hellman key exchange in the control channel (DHE TLS ciphers).

How bad is it?

The CVSS 3.1 base score of CVE-2002-20001 is 7.5, indicating high severity but is not critical. However, it should be mentioned that a denial-of-service attack affects only availability. Since confidentiality, integrity, and scope are not affected it cannot achieve a higher base score, so this is practically the highest possible severity for a denial-of-service attack. However, an attacker can exploit the vulnerability and perform a denial-of-service attack with a low-bandwidth network connection without authentication, privilege, or user interaction. Along with the fact that this vulnerability cannot be fixed, as it exploits a particularity of the Diffie-Hellman key exchange algorithm, it can be mitigated in some ways.

What should I do?

You can mitigate the vulnerability or significantly decrease its effectiveness in the following ways:

Disabling the Diffie-Hellman key exchange algorithms in the application server configurations mitigates the vulnerability.
1. It should not cause compatibility issues with older client applications as there is a well-known key exchange algorithm (RSA) that they support. However, it must be noted that RSA key exchange does not provide forward secrecy.
2. It should not cause compatibility issues with modern clients as they support ECDHE key exchange, which provides forward secrecy and performs much better than DHE.
Using application server-specific rate limitation techniques can effectively reduce the risk of a successful attack.
Using applications that rate-limit suspicious clients by their addresses (e.g., Fail2Ban) can effectively reduce the risk of a successful attack.

Q&A

Why is it called the DHEat attack?

DHEat attack named after that it can heat the CPU by forcing the victim to perform the CPU-intensive operation (modular exponentiation) of the Diffie-Hellman key exchange (DHE) in given cryptography protocols (e.g., TLS, SSH, IPsec, OpenVPN, …).

Is this a design flaw in TLS/SSH/IPsec/OpenVPN protocol specification?

Yes, it is.

Am I affected by the weakness?

It depends on your server configuration. If it enables Diffie-Hellman key exchange, you are affected. However, the effectiveness of a potential attack highly depends on the cryptographic protocol and library implementation details, and key size used during the key exchange.

How is it possible that a 20-year-old weakness is still present?

Any security weakness can survive without publicity. Security issues in the Diffie-Hellman key agreement protocol, including this denial-of-service (overloading) attack, has already been known, but now the effectiveness is demonstrated.

How widespread is the Diffie-Hellman key exchange?

Quite widespread. Diffie-Hellman is part of well-known cryptographic protocols, such as Mbed TLS, GnuTLS, OpenSSL, etc. Most cryptographic protocol libraries support it, and many servers still use it. However, the portion can vary from protocol to protocol. The cryptographic protocol and the application protocol influence the usage ratio. Independently from the fact that the elliptic-curve-based version of the Diffie-Hellman (ECDHE) is preferred over the original version (DHE), the attack can work. It is sufficient that DHE is enabled in the server configuration, but it is not necessary to be preferred.

DHE mainly provides backward compatibility with older client applications that do not support ECDHE but has an essential advantage over the RSA algorithm in that it provides forward secrecy. Forward secrecy is a property of the key exchange algorithms that makes them future-proof. If the key is exchanged using an algorithm with this property, the eavesdropped encrypted traffic cannot be decrypted even if the master secret has been compromised.

The reason why DHE is still popular in the case of Transport Layer Security (TLS), Secure Shell (SSH), Internet Protocol Security (IPsec), and OpenVPN is the fact that it provides both backward compatibility and forward secrecy. Except in terms of TLS, usually, the performance is not so critical, as the application servers of SSH and VPN (Virtual Private Networks), like IPsec and OpenVPN, have protocols that handle a relatively small number of new connections. As the cryptographic handshake is rare, a key exchange algorithm with lower performance (DHE) is acceptable, especially given that forward secrecy is particularly important in the case of remote access protocols like SSH and IPsec.

Among the web servers of the top 100 domains, the Diffie-Hellman key exchange support is extremely low. Among the top 10 thousand domains, the ratio of the servers supporting DHE is higher than 25%, which is still not so high. In the case of the top 1 million domains, the ratio is 45%, which can be considered high, especially if we consider the fact that there are more than 25 million HTTPS servers, according to Shodan. If the ratio is similar in general as in the top 1 million domains. In that case, more than 10 million servers could be connected to the internet using the Diffie-Hellman key exchange.

What are the most popular key sizes in web servers?

The vast majority of the web servers use a 2048-bit key size, where the attack can be effective. The ratio of the 1024-bit key size is still so high because the Logjam attack is estimated to be successful by a state-level attacker. It should be noted that TLS 1.2 initially supported only one key size, but an extension (RFC 7919) allows for negotiating the key size part of the handshake. This extension is part of the TLS 1.3 protocol definition. However, unlike other cryptographic libraries (e.g., GnuTLS, OpenJDK, WolfSSL), OpenSSL does not support the extension TLS 1.2 and supports Diffie-Hellman key exchange in TLS 1.3 before version 3.0.

Should I disable DHE support on my server?

It depends. Suppose you cannot use other mitigation mechanisms, and the clients support the elliptic-curve variant of Diffie-Hellman (ECDHE) or RSA key exchange. You can disable the algorithms using the Diffie-Hellman key exchange in that cases. However, you should consider using RSA key exchange firmly as it does not provide forward secrecy.

How can a server be fixed?

A security update cannot fix a server as it is not an implementation issue but a cryptographic protocol particularity. However, there are effective mitigation mechanisms. They described on the GitHub page the vulnerability’s proof-of-concept code.

How should I change a server configuration?

Diffie-Hellman (DHE) key exchange may be disabled. You can find configuration snippets on the GitHub page of the DHEater project and complete configuration files on moz://a SSL Configuration Generator for several SSL/TLS server implementations and a detailed description about configuring OpenSSH on their guideline page.

Can I detect if someone has exploited this against me?

Yes, you can, but it may require configuration changes. An application server can log that a client connection was interrupted during the cryptographic handshakes. It may occur under normal circumstances but can be considered suspicious behavior. The high number of log messages about connection lost during the handshake part makes it probable an attack.

Has this been abused in the wild?

We don't know. The security community should deploy TLS, DTLS, SSH, IPsec, and OpenVPN honeypots that entrap attackers and warn about exploitation attempts. The HTTPS-based denial-of-service attacks against Cloudflare and Google cause suspicion that attackers are trying to exploit the vulnerability of encrypted protocols.

Does TLS client certificate authentication mitigate this?

Unfortunately, not. The server sends a client certificate request after doing the CPU-intensive part of the Diffie-Hellman key exchange. The client can enforce the computation even if it would be authenticated by a certificate later in the cryptographic handshake.

Does TLS 1.3 mitigate this?

Yes and no. The standard of TLS 1.3 contains the Diffie-Hellman key exchange. Moreover, it defines a mechanism (supported groups) that makes it possible for the client to choose the key size, unlike the early versions of TLS (<1.2), where the server determines the key size. TLS 1.3 (also TLS 1.2 by extension) allows negotiating the key size during the cryptographic handshake. A malicious client can force the largest key size enabled in the server configuration, which can significantly increase the effectiveness of the attack. It should be noted that OpenSSL implements key size negotiation from its version 3.0 only in the case of TLS 1.3. In contrast, other libraries (e.g., GnuTLS) may implement key size negotiation also in TLS 1.2 (RFC 7919).

Does strong authentication mitigate this in the case of SSH?

Unfortunately, not. The authentication layer protocol is intended to be run over the transport layer protocol. The protocol assumes that the underlying protocols provide integrity and confidentiality protection, so the Diffie-Hellman key exchange has already finished before a client authentication starts.

Does strong authentication mitigate this in the case of IPsec?

Unfortunately, not. In the case of the Internet Key Exchange (IKE) protocol, independently from its version, while setting up a security association (SA), the key exchange phase precedes the authentication phase. The Diffie-Hellman key exchange has already finished before a client authentication starts. It is true both in the main and aggressive mode.

Does Diffie-Hellman key size decrease solve this?

Partially. Now Diffie-Hellman keys with a size greater than 2048 bits are considered secure. The 2048-bit is the most widespread key size in the case of former TLS versions, and it would not be wise to suggest using a key with a smaller key size, even though the attack can be effective using a 2048-bit key. In addition, some protocols make it possible to negotiate the key size, so a malicious client can force even a 4096 or 8192-bit key length, which may increase the required CPU computation and the attack's effectiveness. The problem in the case of SSH, IPsec, and TLS 1.3 is similar.

Is this equally effective for each cryptographic protocol?

No, the effectiveness depends on the cryptographic protocol. In the case of TLS, only a ~100 bytes long message (Client Hello) is required to be sent to enforce the DHE key exchange. Other cryptographic protocols also require only two to three messages to be sent and one or two messages to be received to force the CPU-intensive part of the handshake. These messages are generally small, and generating them requires no computation regarding the client side. Message sizes can be decreased after discovering the server settings by offering only the necessary parameters in the initial client messages. These initial messages can be prefabricated in several cases, so they do not have to be computed on each connection, increasing an attack's effectiveness.

Is this equally effective for opportunistic TLS?

No. In opportunistic TLS protocols, upgrading the plain text connections to encrypted ones requires extra effort. Practically, achieving the TLS handshake phase requires one or two round trips, meaning delay and additional data must be sent and received, making the attack less effective. However, it does not change the point.

Is this equally effective for each opportunistic TLS using protocols?

No. Details of the opportunistic TLS protocols differ from each other. Some protocols require only one extra roundtrip (e.g., LDAP, PostgreSQL, RDP), while others require two roundtrips (e.g., FTP, IMAP, POP3, SMTP), meaning that delay and bandwidth values may differ. However, it does not change the point.

Is this problem not being addressed in the related RFCs?

Unfortunately, not, or partially at most. In some cryptographic protocols (e.g., IKE), there are cookies. These cookies are random numbers sent by the server and should be sent back by the client. It makes the prefabrication of the cryptographic handshake messages impossible, so the client must calculate each message in each connection. However, this is a satisfactory solution only in theory, as in practice, it cannot reduce the attack's efficiency to a sufficient degree.

Is this problem not being addressed in application servers?

In some cases, application server implementations have a solution that can reduce the efficiency of an attack or can mitigate it under some circumstances by limiting the number of concurrent (unauthenticated) connections (e.g., OpenSSH, Tectia SSH). For the server configuration details and its effectiveness, see the DHEater GitHub page.

What could be done to prevent this, in theory?

Applying proof-of-work systems (POW) to cryptographic protocols could solve the problem. It would mean that the servers would require the clients to correctly solve a mathematical puzzle before starting the cryptographic handshake if the server is under a denial-of-service attack. The puzzle requires only a minimal amount of computation on the client side. Still, those clients that try to establish many connections simultaneously would be unable to do so because of the computational cost. Client Puzzle Protocol (CPP) implements that kind of system.

Can I just ban someone who has exploited this against my public service?

It depends. It may carry considerable risk and cannot mitigate the attack. The risk is that an attack comes from an extensive private network containing some hundred or thousand devices. If this private network uses network address translation (NAT), the attacked service can ban only the public address of the network. Banning this address causes none of the devices from that extensive private network can access our public service (e.g., website). It cannot solve the problem, as in possession of a large enough botnet, the number of the available IP addresses is sufficient to keep the attack continuous. If you decide on banning the attacking IP addresses, you can find the configuration details on the DHEater GitHub page.

Can I just ban someone who has exploited this against my private service?

Yes, with limitations. It carries almost no risk to ban the IP address wherefrom a private service’s vulnerability is exploited in a time-limited manner. For the details of the configuration, see the DHEater GitHub page.

Will you publish the proof of concept?

We have already published a proof of concept code, DHEater. I named it after the attack, and now it proves the concept in the case of TLS and SSH protocols.

About the author

Szilárd Pfeiffer

Balasys - Security Engineer & Evangelist

Szilárd Pfeiffer graduated from the University of Óbuda with an electrical engineering degree. He gained 15+ years of experience developing network security products in C/C++ and Python languages. During these years, developments have been made in a Linux environment using free software. As committed to free culture and content, network, and data security, he is a regular speaker at conferences and training and regularly publishes articles on these topics. With many years of development leadership behind him, he believes in agility. He currently works as a security engineer and evangelist at Balasys IT Security. Its primary responsibilities include expert participation in R&D projects and IT security evangelism. He develops a command-line tool and Python library for checking cryptographic (TLS/SSL/SSH) settings of client/server applications under a free software license in his spare time.

Contact

About Balasys

Balasys is a Hungarian IT security solution provider. It focuses on implementing Zero Trust solutions and developing flexible software in perimeter defense, legacy server protection, API, and Industrial Control Systems (ICS) security.

To learn more about Balasys, visit www.balasys.eu.