I have the same problem, I'm confused with two tests results. please consider these two cases:

1. secure renegotiation : Supported

secure client initiated renogitation: Not- Supported

2. secure renegotiation : Not-Supported

insecure client initiated renogitation: Not- Supported

In the first case, the server implemented rfc5746 recommondations and supports secure renegotiation, meanwhile if a client initiates a secure renegotiation, the server refuses the renegotiation although it supports secure renegotiation! Is that true? if so, does it make any sense? Administrator could disable renegotiation without supporting it, same as case 2 I think. It seems that in second case, although the server doesn't support secure renegotiation but it has disabled renegotiation at all.

So, Ivan, if I'm true please tell me about these two cases differences and possible vulnerabilities. I have thought of it days and nights but didn't come to any conclusion. Thanks for your help.

The "Secure renegotiation" line tells you if a particular server implements RFC 5746. Client-initiated renegotiation is a separate functionality, and could apply to both secure and insecure renegotiation.

So, in your example, the first server supports RFC 5746; the second does not. If you're asking if there is a practical difference between the security of the two -- yes, there could be. It is also possible that a server initiates renegotiation. It is not possible to test for this, but let's assume that both servers have that facility. In that case, the first server can negotiate securely, the second cannot.

I understand I can use openssl s_client to determine if secure renegotiation is supported, and sslyze can tell me that as well. What I haven't been able to determine is how to check for the inverse, whether or not insecure renegotiation is supported. What command can I use or output should I look for to see this? In other words, what does the SSL Labs test use on the backend to determine line 3 above?

Just a quick update on this, since I re-read Ivan's blog it is a little more clear:

To test for insecure 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 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.