Default DHE group

[Zeev Tarantov]

Since openssl verion 1.1.0, code for TLS server can use
`SSL_CTX_set_dh_auto(ctx, 1);` to let openssl handle choice of DH group
which will be used to generate ephemeral keys if a DHE cipher suite is
negotiated.

TLS 1.3 limits DHE parameters to use groups from RFC 7919, from ffdhe2048
to ffdhe8192.
Reference: https://tools.ietf.org/html/rfc8446#section-4.2.8.1

I'm looking at the function ssl_get_auto_dh in github master and you get
one of:
RFC 5114 DH_get_1024_160
RFC 5114 DH_get_2048_224
RFC 3526 BN_get_rfc3526_prime_3072
RFC 3526 BN_get_rfc3526_prime_8192

Because SSL_CTX_set_dh_auto does not use the values from RFC 7919,
application developers choose to not use SSL_CTX_set_dh_auto.
See for example this commit to nginx web server:
https://hg.nginx.org/nginx/rev/1aa9650a8154

I also cannot really recommend postfix switch to SSL_CTX_set_dh_auto from
the hardcoded default generated by the postfix developers (
https://github.com/vdukhovni/postfix/blob/postfix-3.4/postfix/src/tls/tls_dh.c
).

Patching software using openssl to use RFC 7919 groups "manually" does not
scale well. Expecting server admins to configure this at install time is
laughable.

The situation is so dire, Google Chrome famously decided there are so many
RSA-2048/DHE-1024 web servers deployed, that disabling DHE is the right
thing to do!

In case dh_auto was set, why doesn't openssl use the RFC 7919 groups also
with TLS versions below 1.3?
They are much more reputable than RFC 5114, which is what you get with an
RSA-2048 certificate, which is most common.

If this is fixed, maybe maybe TLS server software using openssl will be
able to switch to SSL_CTX_set_dh_auto, which will result in many more
server using secure key agreement. The alternative is that slowly people
will converge on the Google Chrome decision to disable DHE. Maybe it is
already too late, but perhaps with can still be done in openssl 1.1.1.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190319/01157250/attachment.html>