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 22.214.171.124 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.
This video provides the steps to configure the Cisco Threat Response (CTR) and ESA Integration.
This is live on the portal:https://video.cisco.com/video/6159336218001
And on YouTube:https://www.youtube.com/watch?v=UCKIdx5rdFg
Hello All, We have a remote office where we run a standalone FTD 2140 appliance. Now there is the need to add that appliance to an existing FMC. The 2140 appliance has locally configured routing (inside & outside interfaces), several s...
Can anyone describe how PAP works between ASA and Microsoft NPS for RADIUS authentication and how MS-CHAP is different?Please don't tell me that PAP sends the password in clear text. I have taken PCAPs and I see no clear text shared secret or passwords be...
Good morning... We are using 5545X's and are wanting to use RADIUS as our Network Policy Server (Server 2016) to authenticate access to our ASA's. The problem we are seeing is that when we are configuring the RADIUS server, we successfully login to t...