Stop recommending DHE, because of "dheater" vulnerability

[patrakov]

These guys found a way to saturate the server CPU core to 100% using as little as 5 KB/s of incoming traffic. The pre-requisite is that the server supports DHE as the key exchange. Therefore, to avoid creating such a vulnerable configuration, I propose removing DHE from all levels of SSL config.

[tomato42]

1. It's a well known property of DHE that it's more computationally intensive than RSA and ECDHE key exchanges.
2. Not every named vulnerability is important or requires an action

[Gunni]

CVE-2002-20001 has been assigned for DHE.

[ghen2]

It's a well known property of DHE that it's more computationally intensive than RSA and ECDHE key exchanges.

This is not about the (well known) performance difference under normal usage. This novel technique lets an SSL client trivially occupy 100% CPU on the SSL server by sending rogue data, ie. without requiring a corresponding computational effort from the client. This is an easy DoS attack, which can be mitigated by disabling DHE, or by rate limiting new connections per client (which not all SSL servers can do).

[tomato42]

It's a well known property of DHE that it's more computationally intensive than RSA and ECDHE key exchanges.

This is not about the (well known) performance difference under normal usage. This novel technique lets an SSL client trivially occupy 100% CPU on the SSL server by sending rogue data, ie. without requiring a corresponding computational effort from the client. This is an easy DoS attack, which can be mitigated by disabling DHE, or by rate limiting new connections per client (which not all SSL servers can do).

That's the case for all DH requests from the client, be it FFDHE or ECDHE, no ClientHello (not even in TLS 1.3) includes proof of work or proof of freshness of the key share, at the same time the server has to generate a fresh key share and calculate the shared keys (the processes that use up the CPU time).

Even on a very fast CPU, you can't expect more than ~2k ECDH key exchanges per second per core with a P-384 curve. With the massive 379 byte large TLS 1.3 Client Hello from OpenSSL 1.1.1 that translates to something like 1MiB/s of traffic (after including connection establishment) to fully saturate a core. That's residential broadband levels of upload.

Does that qualify as a DoS too? At what point we can't add support for a stronger, but slower algorithm because that would make the server vulnerable?

[patrakov]

There is a huge difference between 5 KiB/s (that's what dheater generates) and 1 MiB/s mentioned in the previous comment.

[tomato42]

Read my answer again:

1. 1 MiB/s is unoptimised, those are not minimal ClientHello's
2. those are values for different CPUs, I got an example from a top of the line desktop CPU, on a virtualized host on a hosting provider you can easily get performance few times worse, maybe even 10 times worse

So I wouldn't be surprised if to perform the same kind of attack against the same machine as they did but with ECDH you wouldn't need more than 30KiB/s of traffic, and I'm quite sure it wouldn't be more than 100KiB/s

So again, at what point is a cryptographic algorithm a vulnerability?

[watchingdogs]

There is a huge difference between 5 KiB/s (that's what dheater generates) and 1 MiB/s mentioned in the previous comment.

Don't trust what the tool says for bandwidth, make you own measurement because it can be inaccurate.

So again, at what point is a cryptographic algorithm a vulnerability?

Solving this issue isn't done removing support for DHE, but rather making people aware of it and they'll be able to act up on their knowledge, by maybe setting up a firewall. At least a notice for this vulnerability would be beneficial.

[c0r0n3r]

IMHO it would be an appropriate compromise to add an option to the generated configurations to control the used named groups whenever possible. It would be necessary because, in the case of TLS 1.3 (and TLS 1.2 with RFC 7919 support), the clients are allowed to negotiate FFDHE parameters with any key sizes which enabled in the server's configuration. It means that an attacker can exploit that mechanism to force to use the largest allowed key size to overload the server, as the proof-of-concept code (DHEater) of CVE-2002-20001 demonstrate. The default value of named groups may contain the large FFDHE groups (e.g., OpenSSL 3.0, GnuTLS), meaning that the server is highly vulnerable to the DHEat attack using the default. Setting the named groups to contain only the smaller FFDHE groups would solve the problem without security concerns.

[domdom82]

I agree with @c0r0n3r making the named groups configurable is a fair option. I was working on hardening my HAProxy config and quite frankly, the current recommendation by the mozilla ssl generator makes TLS 1.3 more vulnerable than TLS 1.2 to this attack. The dh-param option allows me to limit the key size to 2048 bit but it only works for TLS 1.2.
For TLS 1.3, I needed to add the "ssl-default-bind-curves x25519:secp256r1" option, because OpenSSL 3.x re-introduced DHE again.
So, it would have helped me save a lot of time if the ssl-generator at least had the option to configure named groups / curves.

[c0r0n3r]

The related technical paper (D(HE)at: A Practical Denial-of-Service Attack on the Finite Field Diffie–Hellman Key Exchange) may help your decision.

[gstrauss]

TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 is one of the ciphers recommended by RFC 7905 (published June 2016), and was added to the ssl-config-generator Intermediate configuration in 2023 after discussion in mozilla/server-side-tls#285

I personally agree that DHE ciphers (non-ECDHE) should no longer be recommended for Modern and Intermediate and am also pushing for this change, which as @ghen2 noted above has also been discussed in mozilla/server-side-tls#268 (which was opened in 2020, prior to mozilla/server-side-tls#285 from 2023)

[c0r0n3r]

There is another issue (CVE-2024-41996) which should also be considered. This one and the other two issues (CVE-2002-20001, CVE-2022-40735) are discussed in my article.

[janbrasna]

When the DHE suites are included, we also explicitly set the param to be equal to the ffdhe2048 group (which is the current size for intermediate) — that's why I'm a bit concerned about #256 changing that to RFC 7919 without any restriction allowing unnecessarily large group negotiations.

I consider the more specific issues actually implementation bugs (mostly regressions from 1.1.1x) that are being addressed over time: openssl/openssl#18480 (3.1.0), openssl/openssl#18793 (3.0.6), openssl/openssl#25088 (future 3.4.x release and a backport perhaps?) — silently expecting when the efficiency is being added for safe primes, it means not only for named groups, but also for provided params equal to the groups.

(All the relevant CVEs refer to this issue here, so I'm linking the OpenSSL fixes for posterity.)