Monitor Certificate - SSL handshake

Certificate -SSL handshake - Monitor

So, the certificates which are used on Transport level during SSL handshake can be monitored using Network monitoring tool such as Netmon.

https://www.microsoft.com/downloads/en/details.aspx?FamilyID=983b941d-06cb-4658-b7f6-3088333d062f&displaylang=en

 

Once we have the tool ready and installed on server , we can capture the traces by following below steps

  • 1. Launch the netmon application
  • 2. Go to the Start Page tab
  • 3. Click Create a new capture
  • 4. Click the Start button on the toolbar.  
  • 5. Make a call from client application.
  • 6. Click the Stop button on the toolbar, once the client receives the response.

 

Use the File->Save As option to save the traces in the “.cap” format, naming them as client and service accordingly

 

Reading the traces.

Now when we try to read this file, add a filter as shown below.

 

 In the above screen you will find a series of steps occurring for SSL Hand shake.

1) SSL: SSLv3 Rec Layer-1 HandShake: Client Hello.

2) SSLHandshake: SSL HandShake Server Hello Done(0x0E)

3) SSL: SSLv3 Rec Layer-1 HandShake: Client Key Exchange.; SSLv3 Rec Layer-2 Cipher Change Spec; SSLv3 Rec Layer-3 HandShake: Encrypted Handshake Message.

4) SSL: SSLv3 Rec Layer-1 Cipher Change Spec; SSLv3 Rec Layer-2 HandShake: Encrypted Handshake Message.

5) SSL: SSLv3 Rec Layer-1 SSL Application Data

 

See below screen to get more in-depth view of these steps:

 

Client Hello ( Basic protocols settings/version to be worked/ agreed on )

ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested CipherSuites and suggested compression methods. If the client is attempting to perform a resumed handshake, it may send a session ID.

 

Server Hello Done ( server requesting client to provide a certificate )

 

ServerHello message, containing the chosen protocol version, a random number, CipherSuite and compression method from the choices offered by the client. To confirm or allow resumed handshakes the server may send a session ID. The chosen protocol version should be the highest that both the client and server support.

 

Key Exchange (this is all we can see, since this is an encrypted – ssl channel)

ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate.

ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption parameters were present in the server certificate). " The ChangeCipherSpec is itself a record-level protocol with content type of 20.

 Finally, the client sends an authenticated and encrypted Finished message, containing a hash and MAC over the previous handshake messages.

 

 

NOTE:

Anything which is a personal information attached to the certificate cannot be read at this point.

The information can only be read on server who can decrypt the channel (like what we do in the service, to read the certificate related info).

 

Completion of SSL handshake

 

 The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.

Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted, if encryption was negotiated)."

The server sends its authenticated and encrypted Finished message.

The client performs the same decryption and verification.

 

Get request on method/ operation