DHE Vulnerability of CVE 2022-40735

Customers have asked about CVE 2022-40735 (https://nvd.nist.gov/vuln/detail/CVE-2022-40735) and whether they are vulnerable as users of wolfSSL. The short is answer is: No. But, there are ways that you can put yourself at risk. Let’s delve into the CVE and how best to protect yourself from attacks like this.

First of all, a description of the CVE is in order to be able to have a proper discussion. The attack centres on the use of DHE in a protocol like TLS where the server uses a large private or large parameters. The actual attack is not clear as we haven’t seen the corresponding paper at time of writing. Despite a minimal description, we can make some good security decisions to protect ourselves.

The attack has a client sending one or more messages to the server to initiate a DHE key exchange. In TLS 1.2, this means the client starts a handshake and negotiates a DHE cipher suite. In TLS 1.3, the client sends a DH key share and only lists support for DH named groups (not named curves). The attack come from the client having to do very little work while the server needs to generate a key pair.

In TLS 1.2, the server generates a key pair first and sends the DH parameters and public key to the client. The client at this point can drop the connection and start again. In TLS 1.3 the client can send the same key share over and over again and drop the connection when the server sends its public DH key.

The amount of work the server has to perform for DHE can be quite large. DHE operations are known to be quite slow and there are ways it can be even slower.

Generating a key pair for the exchange involves generating a random private key and calculating a public key. A private key can be as big as the order - the number of distinct values that can be reached by exponentiating the generator (g). The order is about the same size as the prime modulus.

Wisdom past was that you generate a private key large enough to cover the order. But this is a waste! A 2048-bit DH key has only 112 bits of security. Given that it is very hard computationally to find private key from public key, it turns out 224-bits of private key will suffice. Modular exponentiation with a 2048-bit exponent (private key) will be about 8 times slower than with a 224-bit exponent!

wolfSSL will use a small, but secure, private key when the order is not known and when using named groups.

The CVE describes the attack as a Denial of Service (DoS). That is, the server is too busy generating DH keys to do anything else. But how powerful is the server? How many connections can it handle concurrently? These are questions that you should answer based on your setup.

If a server thread is only expected to handle tens of connections a seconds and the number of DHE operations per second is significantly more, then there is no issue! But if the number of DHE operations per second is close to the required number of connections then some changes need to be made.

Another part of the attack is forcing the server to use larger parameters. For reasons of enhanced security, a server may configured to be able to use the named groups of 2048, 3072 and 4096 bits. On a modern Intel x64 server, say, 4000 2048-bit DHE key generations can be completed in a second. But for 3072-bit DHE only 2000 and for 4096-bit key generations only 1000. Therefore understanding how many connections you want to support compared to how many DHE operations that can be performed per second is important.

So using appropriate sized parameters is an important mitigation if you are to use DHE cipher suites with TLS. Ensure the server is only configured to support parameters of a size that you can handle.

An alternative mitigation is to not use DHE in your TLS handshakes. ECDHE is quite commonly supported and popular. Using X25519 can be 5 times faster than 2048-bit DHE.

There are other mitigations that involve detecting and protecting against DoS attacks. One mechanism is to detect malicious clients and block them or time them out. These protections are considered best practice and should be implemented even when not protecting against this CVE.

In summary, wolfSSL is not vulnerable to the issue of long private keys in DHE key generation as described in CVE 2022-40735. Consider carefully, though, the size of the DHE parameters you allow on you server. The relative performance of DHE operations to connection requirements may mean you should be switching to ECDHE anyway.