nCircle VERT Blog

Recently I had a chance to work on an issue related to an older TLS Renegotiation issue , and realized that I didn't understand that issue as well as I thought I had in past.

I used to use following command to test whether a target is vulnerable for this issue:

#openssl s_client -connect 192.168.2.111:443

After the SSL channel is established, simply type 'R' to renegotiate. If the channel is still on, a conclusion of 'target is vulnerable' will be made. Apparently, this method isn't that correct without deeper inspection.

The reason is that this vulnerability is a protocol bug rather than an implementation problem. So, when this bug was discovered and discussed, the only solution vendors had was to disable renegotiation in TLS, like OpenSSL 0.9.8l does. However, Sometime after the release date RFC 5746 was developed to polish TLS renegotiation protocol.

http://tools.ietf.org/html/rfc5746

In this modification, secure renegotiation protocol is implemented. The major reason for the previous design is the fact that the old handshake (before renegotiation) and new handshake
(after renegotiation) are distinct. So when the client initiates a handshake to the server, it doesn't have method to determine if this is a new handshake or a fake renegotiation from an attacker, which allows the attacker to MITM the connection and inject traffic.

With the secured renegotiation protocol, RenegotiationInfo is created. This structure may include client_verify_data or server_verify_data to bind the two handshakes. Here is how it works:

When a new connect is established, the server will include an empty RenegotiationInfo to client, to tell that this is a new handshake. If it is not empty, it is implied that this is renegotiation handshake. Also, the client verify the RenegotiationInfo content. If the client_verify_data or server_verify_data wasn't its own, it will sent alert and drop the channel.

For more details, the above RFC link is a pretty good resource. Let's go back the old method I used for this issue. It will still works well if you do more inspection in the process. Still use same command:

#openssl s_client -connect 192.168.2.111:443

You may notice that right after the CIPHER info line there is a line that indicates whether the target has secure renegotiation or not:

CIPHER is DHE-RSA-AES256-SHA
Secure Renegotiation IS supported

This line indicates that the server already implements the protocol in RFC 5746, and is not vulnerable to this bug, even typing 'R' will not cause it shutdown.