SSL Legacy Renegotiation vs Secure Renegotiation Explained using Wireshark

SSL Forward Proxy Explained using Wireshark

Quick Intro

This is just a quick but in-depth look into SSL/TLS Renegotation and Secure Renegotiation. I'll just quickly show you how legacy and secure negotiation work in TLS/SSL. Renegotiation takes place in the same TCP connection. Do not confuse with Session Resumption/Reuse which takes place in subsequent TCP connections.

Here's the topology I used to test this:

1. Legacy Renegotiation

First there is a full SSL handshake:

Notice that on Frame 6 (Server Hello) BIG-IP offers a Session ID:

However, we do not use this session ID in renegotiation. Why? Because renegotiation means we want to renegotiate security parameters again and reusing session ID we would be reusing the same security parameters.

Also, renegotiation takes place over the same TCP connection, so if client is the one that starts renegotiation we see a straight Client Hello still over the same connection above and full handshake takes place:

If it's BIG-IP (server-side) who is willing to trigger renegotiation then we see a Hello Request message still over same TCP connection followed by full handshake:

That's it. This is legacy Renegotiation.

Note: Do not confuse Renegotiation with Session Reuse/Resumption. In Session Reuse a new TCP connection is open and Client sends a Session ID from a previous session so that same security parameters are reused.

2. Secure Renegotiation - The Add on!

Secure renegotiation is exactly the same as above with the addition of SSL renegotiation_info extension described in RFC5746.

Note: The only reason for this extension is to avoid man-in-the-middle attack where session is hijacked and attacker tries to renegotiate new session using client's handshake information. This extension saves some information from initial handshake that must be provided upon renegotiation which attacker wouldn't have.

If we click on first Client Hello we see renegotiation_info extension along with other extensions in Client Hello message:

Note: Instead of renegotiation_info extension there is also the option to add TLS_EMPTY_RENEGOTIATION_INFO_SCSV to Cipher Suites list and that means the same thing, i.e. we (or client/server) support Secure Renegotiation.

First message is always blank just to indicate Client supports Secure Renegotiation. Server also signals its support in Server Hello:

At the end of every SSL handshake there is a Finished message sent by both Client and BIG-IP:

If we click on Finished message from Client, more specifically on Verify Data field (assuming it is decrypted) we will see a 12 bytes hash in hexadecimal:

This client-side hash (d5 b7 01 35 b3 d2 d7 2a 54 0e 24 f0) is the result of hash of all handshake messages exchanged at this point mixed with previously negotiated master secret and a mathematical function to make it more secure (random). This allows BIG-IP to validate the integrity of the entire handshake. In BIG-IP's Finished message we can also see the same Verify Data message which its own hash which in turn will also allow client to validate the integrity of the entire handshake:

But why is it important to know that? Because in the next handshake, renegotiation_info (found within Client Hello sent by Client) contains Verify Data portion it sent in previous Finished message (from previous handshake). Then BIG-IP sends its hash concatenated with client in Verify Data portion. Therefore, it is unlikely an attacker could have obtained these values because Finished message is always encrypted.

Let's confirm values match on renegotiation_info on Client Hello sent afterwards in the same TCP connection (frame 1931):