Description of problem: After updating Apache (httpd) from 2.4.48-1 to 2.4.49-1, DH parameters are being ignored. Version-Release number of selected component (if applicable): Upgraded httpd-2.4.48-1.fc34.x86_64 @@System Upgraded httpd-devel-2.4.48-1.fc34.x86_64 @@System Upgraded httpd-filesystem-2.4.48-1.fc34.noarch @@System Upgraded httpd-tools-2.4.48-1.fc34.x86_64 @@System How reproducible: Set up apache, create virtualhosts with SSL certificates (same issue applies on non-SNI main site tho), generate a custom dhparams file with a keylength of 4096 bit, configure custom DH parameters using the following configuration option: SSLOpenSSLConfCmd DHParameters "/etc/pki/tls/private/dhparams_4096.pem" SSLOpenSSLConfCmd ECDHParameters secp384r1 When testing the site using e.g. https://www.ssllabs.com/ssltest/analyze.html, the site will be served with DH 3072 or DH 2048 instead (so dhparams are ignored), however the ECDH parameters are still honored as expected. Appending the dhparams to the SSLCertificateFile also doesn't help. After downgrading to a previous httpd release on Fedora 34, everything works as expected. Steps to Reproduce: 1. openssl dhparam -out /etc/pki/tls/private/dhparams_4096.pem 4096 2. In virtual host: SSLOpenSSLConfCmd DHParameters "/etc/pki/tls/private/dhparams_4096.pem" 3. Restart httpd and test site on https://www.ssllabs.com/ssltest/analyze.html (search for either "DH 2048 bits" or "DH 3072 bits") Actual results: Custom DH parameters are being ignored, while ECDHParameters are still honored. Somehow, DH 3072 parameters are being served when using a 4096 bit certificate, and DH 2048 is served when using a 2048 bit certificate. I don't know where apache is serving these from, these parameters might be compiled in? I hope these are not common DH parameters as this might be a security issue. Expected results: On releases before 2.4.49-1, testing the site would show DH 4096 on TLS1.2 ciphers where DH is used, regardless of the keylength. Additional info: This is a security degradation, or in the case that Apache is now serving common DH parameters, it might even be a security issue.
Apologies, of course the following packages are affected: Upgrade httpd-2.4.49-1.fc34.x86_64 @updates Upgrade httpd-devel-2.4.49-1.fc34.x86_64 @updates Upgrade httpd-filesystem-2.4.49-1.fc34.noarch @updates Upgrade httpd-tools-2.4.49-1.fc34.x86_64 @updates
Hm, interesting, thanks for the report. In 2.4.48 mod_ssl had a callback which provided fallback DH parameters (from OpenSSL) and we switched to the OpenSSL-internal implementation in a patch to 2.4.49. I did not expect this to have affected user-supplied parameters. Note that the *parameters* are not the same as keys, which are generated during the neogiation. OpenSSL encourages use of the built-in parameters over supplying your own, as documented here - https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_dh_auto.html
Thanks for the reply. Qualys SSL Labs thinks otherwise and will degrade websites with DH keys lower than 4096 bits, from a key exchange score of 100 to 90. This is how I found the actual issue.
In both the new and old code the key length used in the temporary DH key is derived from the private key for the SSL vhost, although the algorithm used in OpenSSL is slightly different to the algorithm implemented in mod_ssl. If you use a 4096-bit key you'll get a 4096 bit DH key. We can probably revert to the old behaviour until OpenSSL 3.0, and I think could even then disable use of the OpenSSL parameter selection if a key is present in SSLCertificateFile.
Hm, from what I remember I had to supply "SSLOpenSSLConfCmd DHParameters" with a 4096 bits DH key, even if a 4096 bits SSL certificate was already in use, to achieve the desired result. Otherwise I would never have used this configuration option in the first place. This is something we can test. Not that I have any say on this, but I guess a revert would be a good solution.
(In reply to chotaire+fedora from comment #5) > Hm, from what I remember I had to supply "SSLOpenSSLConfCmd DHParameters" > with a 4096 bits DH key, even if a 4096 bits SSL certificate was already in > use, to achieve the desired result. Otherwise I would never have used this > configuration option in the first place. This is something we can test. If that doesn't work definitely let me know since it should be a bug.
Package: httpd-2.4.51-2.fc36 Build: https://koji.fedoraproject.org/koji/buildinfo?buildID=1844591
I have tested in my environment httpd-2.4.51-2 modification and can see that DH parameters provided in first certificate are now taken in to use. But DH parameters provided via "SSLOpenSSLConfCmd DHParameters " config option are still ignored. Is that expected?
(In reply to Petr Hruska from comment #8) > I have tested in my environment httpd-2.4.51-2 modification and can see that > DH parameters provided in first certificate are now taken in to use. But DH > parameters provided via "SSLOpenSSLConfCmd DHParameters " config option are > still ignored. Is that expected? Yes. This behaviour is kind of quirk of how OpenSSL works and there is not much we can do about it at mod_ssl level, patches in Fedora are merged in upstream 2.4.52 now, so we are inline with upstream.