Re: Default DHE group
On 18/03/2019 23:05, Zeev Tarantov wrote: > 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 Well I don't think that commit is an example of developers choosing not to use SSL_CTX_set_dh_auto because it doesn't use the values from RFC7919. The commit doesn't mention RFC7919 at all and actually predates the publication of that RFC in any case. Rather it seems to be a policy decision to not use fixed DH parameters due to precomputation attacks. That concern would apply equally well to RFC7919 - although I'm not aware of any practical precomputation attacks for non-export grade DH params. I'm also not aware of any concerns raised about the RFC3526/RFC5114 params (other than the 1024 one is quite small - but looking at the logic of SSL_CTX_set_dh_auto it selects a size based on the strength of the other elements in the ciphersuite - so it will use larger DH params where appropriate). > 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! Again, this seems to be mixing up different things. I'm not sure how that is relevant to the RFC7919 vs RFC5114/RFC3526 discussion. > > In case dh_auto was set, why doesn't openssl use the RFC 7919 groups also with > TLS versions below 1.3? In fact OpenSSL does not support DHE in TLSv1.3 at all so it is not a case of using RFC7919 for one protocol version and not for others. There is a PR for adding TLSv1.3 support for this: https://github.com/openssl/openssl/pull/8178 The reason that they aren't supported by SSL_CTX_set_dh_auto() at the moment is that that function was introduced before RFC7919 was published (and in fact 1.1.0 was released in the same month as the publication of that RFC). I notice that the underlying RFC7919 params have been integrated into the latest versions of OpenSSL but only in libcrypto - not in libssl. I'd certainly have no objection to updating SSL_CTX_set_dh_auto() to use more modern parameters in OpenSSL 3.0 (PRs welcome) - although I don't think we could justify backporting such a change to a stable branch (1.1.1). Matt
Default DHE group
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.