Diffie-Hellman small sub-groups

[gvanem]

When going to badssl.com and trying this Red Alert test: https://dh-small-subgroup.badssl.com/
my Chrome correctly (?) returns a ERR_SSL_VERSION_OR_CIPHER_MISMATCH. A less capable browser is supposed to show:

But with:

set CURL_SSL_BACKEND=openssl (or schannel, mbedtls etc.)
curl https://dh-small-subgroup.badssl.com/

there is no such warning and the exit-code is 0.
Only with:

set CURL_SSL_BACKEND=rustls
curl -v https://dh-small-subgroup.badssl.com & echo %errorlevel%

I get this Red Alert as in Chrome:

...
* rustls_connection wants us to read_tls.
* rustls_connection_process_new_packets: received fatal alert: HandshakeFailure
* multi_done[CONNECTING]: status: 35 prem: 1 done: 0
* multi_done, not reusing connection=0, forbid=0, close=0, premature=1, conn_multiplex=0
* The cache now contains 0 members
* Curl_disconnect(conn #0, dead=1)
* Closing connection
* Expire cleared
curl: (35) rustls_connection_process_new_packets: received fatal alert: HandshakeFailure
* Curl_client_cleanup()
35

What's the reason for this?

I went to:
https://github.com/frida/openssl/blob/main/CHANGES.md#changes-between-102e-and-102f-28-jan-2016
https://www.youtube.com/watch?v=noFbyPHXY0A

to understand why such DH small sub-groups are bad. Understood little of it.

[bagder]

What's the reason for this?

The TLS libraries do individual decisions. Perhaps some of them can be made to fail on this setup? This is not something we allow on purpose in curl.

BTW, when using BoringSSL that URL fails with curl as well.

[gvanem]

BTW, when using BoringSSL that URL fails with curl as well.

I don't. So that must be a recent change to BoringSSL. I'll try to rebuild it.

[icing]

The vulnerability is for a server. Which might be why some libs in client mode do not complain. But I am just speculating here...

Of course, once the server key is known, the client communication is exposed. But it seems solely a matter of the TLS stack how to react to this condition. It would be nice to have common behaviour here, but that is not curl's domain. AFAICT, there is not flag to set in OpenSSL with which we could influence this.

[icing]

It seems the recommended way for clients to enforce this is to set specific ciphers, omitting the vulnerable ones. TLS stacks with history might be unwilling to do this for compat reasons. Same would hold true for curl, I believe.

[gvanem]

BTW, there are other tests on badssl.com that succeeds in Chrome (i.e. fails), but passes in curl.

[icing]

rustls uses boring crypto. They want to get away from that, but writing safe crypto code in Rust used to be impossible, at least up to last year.