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.
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.
