TLS Renegotiation and Denial of Service Attacks

Ivan Ristic

Last updated on: December 22, 2022

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.

Show Comments (14)

Leave a Reply to kryadov Cancel reply

Your email address will not be published. Required fields are marked *

  1. Ivan,

    Since SSL Labs is able to detect if secure client-initiated renegotiation is enabled, it would be nice to have a QualysGuard QID to detect this as well.

    Right now we have the following QID that covers the MiTM aspect, but that can be mitigated and the web site could still be vulnerabilty to the DoS aspect.

    QID: 38596 – TLS Protocol Session Renegotiation Security Vulnerability – CVE-2009-3555

    Do you know if there are any plans to make this check a QID?

    Thanks,

    Jon

  2. Hello,

    Very interesting article. What strikes me as odd is that the OpenSSL library does not have a simple option bit to turn off this functionality. I looked at a patch for Apache that turns off the renegotiations, but that code strikes me as very low level.

    I’m trying to make a Python server that uses PyOpenSSL ignore/not support the renegotiations, but because OpenSSL doesn’t support this itself and the wrapper for Python does not allow the really low level access level that Apache uses, I can’t figure out how to do this. Does anybody have any suggestions how to accomplish this using PyOpenSSL?

    With kind regards,

    Sven

      1. Ivan, any news regarding openSSL? I agree with Sven’s remark that there is no easy option in openSSL to disable client-initiated renegotiation (or maybe configure a max. number of client-initiated renegotiations after the initial handshake has been completed…) – but IMHO there should be such option.

        Since this discussion is around a while already, but I did not find any progress anywhere else either, I thought I’ll ask you first, before contacting openSSL…

  3. Thanks for the lucid writeup.

    Question:

    If you are a financial institution and are utilizing SGC or step-up then the client would renegotiate and that would be classified as a Fail on the test of "disallowing client initiated renegotiation". What do you reccommend here?

    How does one pass this test if one is a FI (Financial Institution)?

    1. Guarav,

      If you’re still deploying SGC certificates then you cannot pass the test (because SGC relies on renegotiation, as you said). At best, you could disable insecure renegotiation but enable weak cipher suites, and then deliver a message to your users to upgrade to a newer browser. But such error messages are not very strong, and should not actually be used.

      Are you in such situation? If so, I’d like to talk to you about how many SGC clients you are actually seeing. Please send me a private message. The last version of Internet Explorer to support SGC was IE 5.0 (5.0.1 was issued to remove SGC), so I am expecting that the number of SGC clients is very low.

  4. I notice that the latest version of SSLLabs server test report (v1.22.37) no longer reports secure client-initiated renegotiation as a vulnerability if enabled. Is this an intentional change or a regression in the test report?

    1. I have the same question. I noticed that the latest version of SSLLabs server test report no longer reports secure client-initiated renegotiation as a vulnerability if enabled. Is this an intentional change? Is secure client-initiated renegotiation not a vulnerability?

  5. I too have the same question.
    “I noticed that the latest version of SSLLabs server test report no longer reports secure client-initiated renegotiation as a vulnerability if enabled. Is this an intentional change? Is secure client-initiated renegotiation not a vulnerability?”

    COMODO SSL Analyzer calls it out as vulnerable to DoS but nothing on the Q side.