Dissecting TLS 1.2 Handshake using Wireshark

 


         


Objectives

By the end of this guide, you will

  • be able to make request and find the IP address of any website server by using curl
  • be able to capture and filter packets of a network traffic using wireshark
  • have a basic understanding of TLS 1.2 handshake 

 

For more information about TLS, please read my article about Cryptography & TLS.

 

Prerequisites

  • Wireshark

Run: sudo apt install wireshark  

  • Curl

Run: sudo apt install curl  

 

    Analyzing a TLS handshake 

    1. Use Curl to find the IP address of the web server

     In our example, we will be accessing the following website: 

    https://tls-v1-2.badssl.com:1012/

     

    Run: curl https://tls-v1-2.badssl.com:1012/ -v 

    Basically the curl command allows us to make requests and communicate with the server. 




     

    The IP address of the web server is found to be 104.154.89.105  

     

    2. Open wireshark

     Run: sudo wireshark

     

    3. Capture packets

    Before starting packet capture, please note that we will be performing request to the web server in two ways:  

    (i) via a web browser (Chrome, Firefox)

    • Select the appropriate interface (the one having the IP address of your device) and start packet capture on wireshark. Double click to start capture. Alternatively you can right click and choose start capture.



    • Open the website in your web browser and then stop capture on wireshark.
    •  Use the following filter to display only packets involving the web server of that website which uses the TLS protocol:

    tls && ip.addr==104.154.89.105 

    It can be seen that our device initiates many TLS handshakes (3 Client Hello messages). This occurs because the browser opens multiple TCP connections (3 in this case) to the web server in order to enhance speed and each connection has its own TLS handshake.

     

    3 TCP connections opened by the browser

    (ii) using the curl command

    The same steps as (i) are applied but instead of opening the website on your browser, use the curl command:

     curl https://tls-v1-2.badssl.com:1012/  

    A neater result is obtained since only one connection is made. This makes it simpler to show the sequence of packet messages for the purpose of this article.


    4. Dissecting the TLS handshake 

    (i) The client sends Client Hello to the server 

    Uploading: 93478 of 93478 bytes uploaded.



    At this point all data exchanged are unencrypted and transmitted in plaintext. The message contains:

    • The latest TLS version number that the client supports

    • The client random 
    • The list of cipher suites that the client supports in order of client's preference
    •  Session ID 

     

    (ii) The server sends Server Hello


    The message contains:

    • The chosen TLS version (TLS 1.2)
    • The server random
    • The cipher suite which the server chose from the list (TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)


    (iii) The server sends Certificate, Server Key Exchange and Server Hello Done 



    The certificate message contains:

    •  Certificates the server has 
    • Information about the certificate such as their issuer, their validity, their public key, etc


     



    The Server Key Exchange message contains:

    •  The server's Diffie-Hellman public key


    The Server Hello Done indicates that the server has finished sending over all data.  

     

    (iv) Client sends Client Key Exchange, Change Cipher Spec and Encrypted Handshake Message



    The Client Key Exchange contains:

    • The client's Diffie-Hellman public key



     The Change Cipher Spec lets the server know that the client has generated the session key and is switching to an encrypted environment.

     

    An Encrypted Handshake Message is sent to indicate that the handshake is done on the client side.  


    (v) Server sends Change Cipher Spec and Encrypted handshake 


    The Change Cipher Spec lets the client know that the server has generated the session key and is switching to an encrypted environment.


    An Encrypted Handshake Message is sent to indicate that the handshake is done on the server side.

    All packets hereafter are encrypted. 

     



     

    Comments