Because you cant be a good network engineer if you do not know how to drive wireshark, i decided to put a post up on how to capture and analyse TLS negotiation. For this purposes, I used www.cnn.com. Before you do the capture, its good to do an nslookup for the domain so you can filter out relevant traffic (yes wireshark calls it 'ssl'). But really you can just use the public IP address on your loadbalancer (or F5) if that is what you want to analyse. So hit your website, using https. Once pulled up, stop the capture.
So put a display filter in using 'ssl' as the syntax (sure if you are real smart you could have already used ssl as the capture filter).You might now have multiple TLS sessions t multiple destination, so the output needs to be more granular even. Choose the IP address you are interested in 151.101.81.67 in this case (which is the IP address used by some wanky cloud provider that cnn uses). so let us follow a particular stream:
Following the ssl stream will give you a clear picture of the whole TLS hand shake and exchange of public keys, cert up to the exchange of symmetric key used for further encryption (through for instance AES 256).
the first thing that always happens when connecting using https is the client (your browser) announcing its cipher capabilities, it basically tells the server you are connecting to what security algorithms you are capable of. This is shown in the screen shot below
This is a client Hello, using Chrome v 67, as you can see only Elliptic Curve Diffie Helman predominately. It is also interesting to see that the client attempts TLSv1.2. In the opposite direction a server hello is sent to the client:
Basically the server has decided it will use the securest possible cipher set. in this case ECDH, AES128 and Sha256. This is why it is important to define cipher suites on your webserver/F5 so security cant be forced by the client into using lower security ciphers such as DES or 3DES. by simply removing it from the capability of the server.
So the next thing that would happen, is the server issuing its certificate. As can be seen in figure 5
In Figure 5 you can see the common name of the cert. and the CA (global Sign) and a stack of subject alternative names. After that the cert finalizes the Hello phase with a Hello done. in short:
the next thing that happens is the exchange of "change cipher specs". essentially this is where the negotiation of symmetric session encryption keys takes place that will be used for further encryption of traffic (for instance by means of AES). as can be seen in Figure 6, this happens straight after the server Hello done.
Ofcourse the symmetric encryption keys cannot be exchanged without being encrypted themselves. so in order to hide them from a man in the middle attach, Diffie Helman comes into play. So If i drill into the client key exchange packet, I can see in our example that Elliptic Curve Diffie Helman is being used:
As you can see, all of this TLS exchange is aimed to provide confidentiality and integrity. The actuall exchange of the X509 cert. provides the authentication portion of this.
Namaste
