Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop recommending DHE, because of "dheater" vulnerability #162

Open
patrakov opened this issue Oct 23, 2021 · 8 comments
Open

Stop recommending DHE, because of "dheater" vulnerability #162

patrakov opened this issue Oct 23, 2021 · 8 comments

Comments

@patrakov
Copy link

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
Copy link
Member

  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
Copy link

Gunni commented Nov 23, 2021

CVE-2002-20001 has been assigned for DHE.

@ghen2
Copy link

ghen2 commented Nov 24, 2021

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
Copy link
Member

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
Copy link
Author

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

@tomato42
Copy link
Member

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
Copy link

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
Copy link

c0r0n3r commented Sep 2, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants