mod_ssl Bug and SSL Labs Renegotiation Test
Last updated on: November 3, 2022
Update March 13, 2019: SSL Labs Renegotiation Test is re-enabled on the production instance.
Update March 12, 2019: SSL Labs Renegotiation Test is re-enabled on the development instance, and will be live on the production instance this week.
Update February 20, 2019: To give more time to fix, we will re-enable the SSL Labs Renegotiation Test on March 11, 2019 (two additional weeks).
The Apache Security Team fixed a bug which triggers whenever a client attempts renegotiation with Apache HTTP Server 2.4.37 and OpenSSL 1.1.1. This bug causes the Apache httpd service to consume 100% CPU. Details of the bug can be found at: https://bz.apache.org/bugzilla/show_bug.cgi?id=63052
Local testing by Qualys confirms that the SSL Labs renegotiation test triggers this bug for the above-mentioned server configuration, and can be used to cause the Apache httpd service on a target system to consume 100% CPU.
To allow Apache users time to apply the fix, SSL Labs has disabled the Renegotiation Test for one month, and we will re-enable it on February 25, 2019. While the test is disabled, users will not see the following in SSL Labs reports:
Acknowledgements
We would like to thank the Apache Security Team for working with us on this issue.
Am I correct in assuming that this (really disgusting) bug affects only webservers supporting TLS 1.3 actually ?
If so, it might be sufficient to restrict the no-testing policy to such systems where the new protocol has been detected.
Should we even attempt to renegotiate anywhere amidst of and during a session which is labeled “HSTS” ?
If I have understood this well, HSTS prevents any kind of regenotiation resp. handshaking by simply terminating it (so any MITM intruders won’t even get their dirty hands into this, which is the purpose).
=> WRONG MESSAGE. Session terminated. – is all what such comes off that in case of someone attempting to negotiate…
(TLS 1.2 and TLS 1.3 won’t get switched inbetween and mid-session on a server which only supports these two and has fallbacks prevented).
TLS 1.3 has removed Renegotiation feature.
Openssl 1.1.1 supports TLS 1.3. Those server which are upgraded to Openssl 1.1.1 by default supports TLS 1.3, however server can be configured with TLS 1.3 disabled and SSL Labs cannot detect which version of OpenSSL is used in Apache server.
Does it skip the renegotiation test even if the server says something other than Apache due to it being a risk even behind a proxy, or it is because it doesn’t want to trust the server string to be honest?
Detection of Webserver/Version is not reliable, most may not have enabled it. Due to this reason, we have disabled this test fully to avoid issues for web servers.
Regards,
Yash K.S
Does it mean that if I update my Apache to 2.4.38 then I won’t be susceptible of this bug? That update has been published for quite some time now
http://www.apache.org/dist/httpd/CHANGES_2.4.38
Feb 25 came and went and the tests were not enabled.
Just updated to 2.4.38 from 2.4.37 and the qualys test still causes one httpd server to go to 100% CPU on a single run of the community edition standard test.
This is disappointing given the release notes and known issue. Is there something else that needs to be done? Does the upgrade to the latest 2.4.41 solve the issue? Why is qualys continuing to cause this issue to our Web servers?
Hi Bob,
This issue appears when Apache 2.4.37 and OpenSSL 1.1.1 is used.
This was first reported to us here – https://discussions.qualys.com/thread/19027-apache-threads-stuck-at-100-after-scan
After investigation and help from the community, it was evident that it was a bug in Apache 2.4.37
Apache fixed the bug as mentioned here – https://bz.apache.org/bugzilla/show_bug.cgi?id=63052
Since you’ve mentioned that you’re using Apache httpd 2.4.38 after upgrading it from 2.4.37. I would request you to please check the version of httpd and OpenSSL on the server for which the CPU spikes to 100% while running the server test on SSL Labs
Regards,
Nauman Shah