Compartir a través de

Monitor Certificate - SSL handshake

  • Artículo

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

 

Comments

  • Anonymous
    April 28, 2012
    Hi came across this great post which deals with SSL monitoring. I think it can be reused with or without SCOM. zeglory.blogspot.com/.../ssl-monitoring-using-scom-and.html

  • Anonymous
    May 01, 2012
    SSL monitoring is depends on the handshake technology , good post , and I am using comodo SSL Certificate which is very great in providing SSL certificates

  • Anonymous
    June 06, 2012
    Nice document for SSL handshake,get more about ssl here getdealscode.wordpress.com

  • Anonymous
    January 21, 2013
    Your capture labeled "server requesting client to provide a certificate" should be like "Server Hello. Certificate. Certificate Request. Server Hello Done." But the "Certificate Request" portion is missing.  I am having a similar problem using WCF with HttpsTransportBindingElement.RequireClientCertificate set to true.  My service appears to require a certificate, errors with 403 if the client doesn't provide one, browsers prompt to select a certificate and inside my WCF service I can view the details of the client certificate using ServiceSecurityContext.Current.AuthorizationContext.ClaimSets, but when I use Network Monitor to validate the two-way SSL, I don't see the "certificate request" from the server, nor the "certificate" being sent from the client.  I know it's getting to the service somehow but it seems to deviate from the standard protocol?