According to Ristic, the THC group has released the DoS utility that works at the SSL/TLS layer. The tool, he says, exploits the fact that, when a new secure sockets layer (SSL) connection is being negotiated, the server will typically spend significantly more CPU resources than the client.
In this way, he notes, if anyone requests a large number of new SSL connections in a short period of time, the server starts to become overloaded.
“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”, he says in his latest security posting.
Interestingly, Ristic notes that it is not clear that relying on a TCP/IP session renegotiation helps with the DoS attack, but he adds that since any external DoS mitigation tools – such as a per-session rate-limiting application – being used as a security screen would only see one TCP session, this helps to avoid detection.
But this, he says, is only if your server supports client-initiated renegotiation. If it does not, he adds, anyone wishing to perform a DoS attack against the SSL layer will have to fall back to using one TCP connection for every SSL connection.
Microsoft IIS, he notes, does not support client-initiated renegotiation and, while Apache used to, it changed its behavior 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”, he argues.
Ristic goes on to say that, in order to assist anyone assessing their systems for this weakness, Qualys has updated the SSL Labs assessment tool to test not only if secure renegotiation is supported – which he says his team has 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”, he explained.
“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”, he concludes.