Refine appropriate parameters for DoS risk in TLS client-initiated renegotiation

[mxsasha]

Adjacent to #714 / #1218 but splitting off into a separate issue for readability. Note that this issue is not about insecure renegotiation, which is is always a failure.

The TLS guidelines say:

Allowing clients to initiate renegotiation is generally not necessary and opens a server to DoS-attacks inside a TLS connection. An attacker can perform similar DoS-attacks without client-initiated renegotiation by opening many parallel TLS connections, but these are easier to detect and defend against using standard mitigations.

We test for this, have copied that wording into our explanation, and if it is enabled, this is an info message ℹ️.

Our current test, along with testssl and ssllabs, makes one renegotiation attempt as the client, and if that succeeds, declares client-renegotation is enabled. SSL labs just mentions this, testssl shows a bright red "VULNERABLE (NOT ok), DoS Threat", we say " Your web server allows for client-initiated renegotiation, which could have negative impact on the availability of your website."

However, the sslyze test is slightly different, which I noticed while debugging why www.mmdc.nl detects as "client-initiated renegotiation enabled" in the existing code, but not in our new sslyze based test. Sslyze only counts it as enabled when 10 renegotiations succeed. A DoS risk seems like it would require many renegotiations, so the argument is that if there is a limit <10, that is sufficient mitigation.

Allowing it, but with a low limit seems rare, but one example is www.mmdc.nl. I can confirm with openssl s_client that they allow 5 renegotiations per connection. Therefore, it does seem that our current test may be more strict than would be needed to prevent DoS, which seems to be the reason for this test. However, the TLS guidelines only mention on vs off and don't mention this nuance.

What should be the behaviour of the test when renegotiations are limited to low numbers, but not entirely disabled? And perhaps this nuance can be part of the input for new TLS guidelines as well.

[bwbroersma]

Great input, since the NCSC-NL TLS guidelines are still in review, we can check this with others what is best. However sometimes (like with RTT-0) the TLS guidelines are very conservative, which might be easier to implement.

Questions I have:

• Since testing for this will need X+1 renegotiation, will these extra renegotiation trigger WAFs / IDS rate limiting / blocking?
• What are valid use-cases for client-side renegotiation?

[mxsasha]

Great input, since the NCSC-NL TLS guidelines are still in review, we can check this with others what is best. However sometimes (like with RTT-0) the TLS guidelines are very conservative, which might be easier to implement.

Well, sslyze currently does the 10 attempts, so it is more work to make it fail even if one renegotiation attempt succeeds for us right now :) But mostly, I thought their reasoning was interesting.

* Since testing for this will need X+1 renegotiation, will these extra renegotiation trigger WAFs / IDS rate limiting / blocking?

For servers that have disabled it, there would be no extra traffic: the first attempt fails, and the test is done.

For servers that have it enabled, with or without rate limit, it would not add any connections, but might look a bit more suspicious as multiple renegotiations are attempted. I see that risk as small though, and for those servers, the alternative is now a false detection of a DoS vector.

* What are valid use-cases for client-side renegotiation?

I do not know. I've only ever heard of it in negative ways as a DoS risk.

[mxsasha]

Conclusion from discussion: we will patch sslyze to make the max tries configurable.