HTTPS (TLS/SSL) packet analysis with wireshark. SSL/TLS basics.

Secure Sockets Layer (SSL) is an Internet security protocol  which allows Web applications such as Web browsers, Web servers to transmit information securely in encrypted form.  When accessing a   SSL based Website one can notice that the “http” in the address line is replaced with “https,” and  a small padlock is visible in front of URL in Opera & Mozilla or in status bar at the bottom of the IE.
Transport Layer Security (TLS) is much similar to SSL, and many people term it as SSL3.1. However, both are in-operable with one another.
TLS has been developed on open community standards, which makes it more extensible and most of the open-source applications prefer it.
TLS Handshake Protocol steps are given below:
1.  Client sends a Client Hello message to the server, along with the client’s random value (also called nonce or challenge ) and supported cipher suites.
2.  Server responds by sending a Server Hello message to the client. Server too sends a random value along with the Server Hello message to avoid replay attacks..
3.  Server sends its Certificate to client for authentication and may optionally request a certificate from the client.
4.  Server sends the Server Hello Done message.
5.  If server has requested a certificate from the client, the client sends it.
6.  Client creates and sends server a Pre-Master-Secret encrypted with the public key from the server’s certificate.
7.  Server and client each generate the Master-Secret and session keys based on the Pre-Master Secret.
8.  Client sends Change Cipher Spec notification to server indicating it will start using the new session keys for hashing and encrypting messages.
9.  Server sends Change Cipher Spec notification to Client.
10.Client and server can now exchange Application Data over the secured channel encrypted using session key.
Wireshark is a network protocol analyzer for Windows, Linux and other platforms. It lets you capture and interactively analysis the traffic running on a computer network. An example of HTTPS (SSL/TLS) packet analysis with Wireshark is given below.
We have connected to Gmail (https://accounts.google.com) at 74.125.236.22.
Analysis:
  • In above snapshot, we have set Filter  as ip.addr==74.125.236.22 (GMail server’s IP-Address).  This makes it easy to concentrate on packets related to Gmail only.
  • First three packets shows the Three-way Handshake process of TCP. [Syn-SynAck-Ack]


We can make above Wireshark analysis more compact by restricting to view TLSv1 traffic only:

Analysis:

1.The first TLS packet is a “Client Hello”:
 On concentrating TLS Record (Header/Content) of the packet we find:
  •  The TLS record begins with the same three fields: Content type, Version  and Length. Here, Content type is 22 that is ‘Handshake’, Version is TLS 1.0 and Length is 137.
  •  Then there is ‘Random‘ field which contains a nonce or challenge (in hexadecimal):
 f4:1b:b0:30:90:e7:af:ac:62:81:32:2c:79:67:4f:f2:ea:85:69:55:85:04:91:10:f4:e4:7f:a2
To avoid Replay-attacks, both Client and Server sends nonce or challenge message (32-bit).
  •  Then there is ‘Session ID‘ field: The session ID provides a unique persistent identifier for the SSL session. The client may resume the same session later by using the server-provided session ID when it sends the ClientHello.
  • Then there is ‘Cipher Suites‘ field by which client advertises that it supports 27 different cipher-suites. One of those 27 is  a combination: RSA for public key cryptography, RC4 for the symmetric-key encryption and SHA as hashing algorithm.
 2.  After receiving “Client Hello” TLS packet server responds by sending Server Hello:
 
 The important fields of Server Hello packet are:
  •   Random: To avoid Replay-attacks, both Client and Server sends nonce or challenge message (32-bit).
  •  Cipher Suites: Sever tells client that it uses RSA for public key cryptography, RC4 for the symmetric-key encryption and SHA as hashing algorithm
The important fields of Server Hello packet are:
  •   Random: To avoid Replay-attacks, both Client and Server sends nonce or challenge message (32-bit).
3.    Then server sends Certificate:
The step is self-explanatory, if you wish to analysis in deep, you can analyze the raw dump.
4.  Server sends the Server Hello Done message:
5.  Client Key Exchange: Client creates and sends server a Pre-Master-Secret encrypted with the public key from the server’s certificate. Server and client each generate the Master-Secret and session keys based on the Pre-Master Secret.
6. Client sends Change Cipher Spec notification to server indicating it will start using the new session keys for hashing and encrypting messages.
7. Server sends Change Cipher Spec notification to Client.
8. Client and server can now exchange Application Data over the secured channel encrypted using session key: