false positive Client-initiated Renegotiation report

[blshkv]

Hi it looks like I'm getting a false positive report about subject. Here is the sslyze v0.14.1 output:

  * Session Renegotiation:
      Client-initiated Renegotiation:    VULNERABLE - Server honors client-initiated renegotiations
      Secure Renegotiation:              OK - Supported

However, the ssllabs results are different:

Secure Renegotiation    Supported
Secure Client-Initiated Renegotiation   Yes
Insecure Client-Initiated Renegotiation No

I have done manual testing using openssl library (https://alpacapowered.wordpress.com/2014/10/20/ssl-poodle-attack-what-is-this-scsv-thingy/) and sslyze result looks false positive indeed

Do let me know if you need a web server url, I can send it to you in private (just in case).

Thank you.

[nabla-c0d3]

Hello, I think SSLyze and SSL Labs are saying the same thing:

• The server will let a client start a renegotiation
• The server supports secure renegotiation

However SSL Labs has an extra check where it actually tries to do a client-initiated insecure renegotiation although it already knows that the server supports secure renegotiation. I'm guessing it is to make sure that insecure renegotiations are really blocked.

[blshkv]

Agreed, but can you make it clear too? The report says "vulnerable" and takes a lot effort to understand that it is NOT vulnerable

[deargle]

It's actually possible according to this thread for a server to support both "secure" and "insecure" client-initiated renegotiation, looking like this in SSL Labs:

Secure Renegotiation                        Supported
Secure Client-Initiated Renegotiation       Yes
Insecure Client-Initiated Renegotiation     Yes

That thread suggests it happens when the server supports both "secure renegotiation" and also "insecure renegotiation", and that it accepts client-initiated renegotiation for both kinds. Poster joshk says:

To test for insecure [client-initiated] renegotiation, you must use openssl 0.9.8k or earlier. Any later version will have been patched, and even using the -legacy_renegotiation switch, it will still default to secure [client-initiated] renegotiation if its supported, meaning you can't test for the inverse (the case where both secure and insecure are supported). Using 0.9.8k just run the command:

openssl s_client -connect <host>:443

After connection is successful, enter:

HEAD / HTTP/1.0
R

If it fails, or times out, insecure renegotiation is not enabled. If it connects successfully or gives certificate errors, insecure renegotiation is supported. Hope it helps.