cancel
Showing results for 
Search instead for 
Did you mean: 
Login & Join the DevCentral Connects Group to watch the Recorded LiveStream (May 12) on Basic iControl Security - show notes included.
Related articles:

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:

0151T000003d7L4QAI.png

1. Legacy Renegotiation

First there is a full SSL handshake:

0151T000003d7L5QAI.png

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

0151T000003d7L6QAI.png

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:

0151T000003d7L7QAI.png

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:

0151T000003d7L8QAI.png

That's it. This is legacy Renegotiation.

NoteDo 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.

NoteThe 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:

0151T000003d7L9QAI.png

0151T000003d7LAQAY.png

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:

0151T000003d7LBQAY.png

0151T000003d7LCQAY.png

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

0151T000003d7LDQAY.png

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:

0151T000003d7LEQAY.png

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:

0151T000003d7LFQAY.png

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😞

0151T000003d7LGQAY.png

On BIG-IP's side it is the concatenation of Client's Verify Data and BIG-IP's Verify data (frame 1965😞

0151T000003d7LHQAY.png

That's it.

Comments
Leonardo_Améric
Nimbostratus
Nimbostratus

congratulations!!!

 

Version history
Last update:
‎27-Mar-2019 03:22
Updated by:
Contributors