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.

A group of hackers known as THC (The Hacker’s Choice) last week released an interesting DoS tool that works at the SSL/TLS layer. The tool is exploiting the fact that, when a new SSL connection is being negotiated, the server will typically spend significantly more CPU resources than the client. Thus, if you are requesting many new SSL connections per second, you may end up using all of the server’s CPU.

The issue abused by the tool is not new, but what is new is that we now have a well publicised working exploit, and that always makes you pay attention. In addition, the tool uses the renegotiation feature, which means that it can force a server to perform many expensive cryptographic operations over a single TCP connection. It’s not clear if the relying on renegotiation helps with the DoS attack (there’s a very good analysis of the trade-offs on Eric Rescorla’s blog), however the fact that external DoS mitigation tools (e.g., rate limiting setups) are only seeing one TCP connection certainly helps with avoiding detection.

But that’s only if your server supports client-initiated renegotiation. If it does not, anyone wishing to perform a DoS attack against the SSL layer will have to fall back to using one TCP connection for one SSL connection. IIS, for example, does not support client-initiated renegotiation. Apache used to, but changed its behaviour when implementing RFC 5746 (which fixed the TLS Authentication Gap problem). Even if you depend on a product that does support client-initiated renegotiation, chances are you can easily disable that feature. And, when you do, you are not going to miss it (unlike server-initiated renegotiation, which some sites that require client certificates might need).

To help you with assessing your systems for this weakness, we have updated the SSL Labs assessment tool to test not only if secure renegotiation is supported (which we’ve been testing for some time now), but also to check if secure client-initiated renegotiation is enabled. Previously we only tested for insecure client-initiated renegotiation.

The sensible thing to do is to check for client-initiated renegotiation support in your servers, and disable it where possible. Although that won’t substantially help you overall (defending against DoS attacks is notoriously difficult and expensive), it will harden your defences against this particular technique.