RASHTRIYA RAKSHA UNIVERSITY

Pioneering National Security and Police

University of India An institute of national
importance.
National Security is Supreme!
Lavad – Dahegam, Gandhinagar – 382305

School of Information Technology & Artificial Intelligence

Cyber Security (SITAICS)

M.Sc. / Post Graduate Diploma in

Cyber Security & Digital Forensics
2nd Semester
(Session 2023-24)

Network security and log analysis

Submitted by: Balireddy chandramouli Reddy Submitted to:

Name: -Stefina Macwan
Enrolment no:230031102521058 Assistant Professor

SITAICS, RRU

Page 1 of 9
Analyzing TLS handshake using Wireshark
The below diagram is a snapshot of the TLS Handshake between a client and a server captured using the Wireshark, a
popular network protocol analyzer tool.

Let’s analyze each step.

Page 2 of 9
1. Initial Client to Server Communication

Client Hello

Typically, the first message in the TLS Handshake is the client hello message which is sent by the client to initiate a
session with the server.

The message contains:

• Version: The TLS protocol version number that the client wants to use for communication with the server.
This is the highest version supported by the client.
• Client Random: A 32-byte pseudorandom number that is used to calculate the Master secret (used in the
creation of the encryption key).
• Session Identifier: A unique number used by the client to identify a session.
• Cipher Suite: The list of cipher suites supported by the client ordered by the client’s preference. The cipher
suite consists of a key exchange algorithm, bulk encryption algorithm, MAC algorithm and a pseudorandom
function. An example of a single cipher suite (one of the 28 suites mentioned in the above diagram) is as
follows:

where

TLS = protocol version

RSA = Key exchange algorithm determining the peer authentication

AES_256_CBC = bulk encryption algorithm used for data encryption

SHA = Message Authentication Code which is a cryptographic hash.

• Compression Method: Contains a list of compression algorithms ordered by the client’s preference. This is
optional.

Page 3 of 9
2. Server response to Client

The server responds to the client with multiple messages:

Server Hello

The Server Hello contains the following information:

• Server Version: The highest TLS protocol version supported by the server which is also supported by the
client.
• Server Random: 32-byte pseudorandom number used to generate the Master Secret.
• Session Identifier: Unique number to identify the session for the corresponding connection with the client. If
the session ID in the client hello message is not empty, the server will find a match in the session cache. If a
match is found and the server wants to use the same session state, it returns the same ID as sent by the
client. If the server doesn’t want to resume the same session, then a new ID is generated. The server can also
send an empty ID, indicating the session cannot be resumed.
• Cipher Suite: The single strongest cipher suite that both the server and the client support. If there is no
supporting cipher suite, then a handshake failure alert is created.
• Compression Method: The compression algorithm agreed by both the server and the client. This is optional.

Server Certificate

Page 4 of 9
The server sends the client a list of X.509 certificates to authenticate itself. The server’s certificate contains its public
key. This certificate authentication is either done by a third party (Certificate Authority) that is trusted by the peers,
the operating system and the browser which contains the list of well-known Certificate Authorities or by manually
importing certificates that the user trusts.

Certificate Status

This message validates whether the server’s X.509 digital certificate is revoked or not, it is ascertained by contacting a
designated OCSP (Online Certificate Status Protocol) server. The OCSP response, which is dated and signed, contains
the certificate status. The client can ask the server to send the “certificate status” message which contains the OCSP
response. This approach is known as OCSP Stapling. The process saves bandwidth on constrained networks as it
prevents OCSP servers from getting overwhelmed with too many client requests.

The client, to indicate that it wants a certificate status message, includes an extension of the type

“status_request” in the Client Hello request.

Page 5 of 9
Server Key Exchange

The message is optional and sent when the public key present in the server’s certificate is not suitable for key
exchange or if the cipher suite places a restriction requiring a temporary key. This key is used by the client to encrypt
Client Key Exchange later in the process.

Client Certificate Request

This is optional and is sent when the server wants to authenticate the client, for e.g. a website where the server
needs to confirm the client’s identity before providing access to private information. The message contains the type
of certificate required and the list of acceptable Certificate Authorities.

Server Hello Done

This message indicates the server is done and is awaiting the client’s response.

3. Client response to Server

Client Key Exchange

Page 6 of 9
This message contains:

• The protocol version of the client which the server verifies if it matches with the original client hello
message.
• Pre-master secret – a random number generated by the client and encrypted with the server public key. This
along with the client and server random number is used to create the master secret. If the server can decrypt
the message using the private key and can create the master secret locally, then the client is assured that the
server has authenticated itself.

Change Cipher Spec

This message notifies the server that all the future messages will be encrypted using the algorithm and keys that
were just negotiated.

Finished (Encrypted Handshake)

The Finished message is complicated as it is a hash of all the messages exchanged previously along with a label
(“client finished”). This message indicates that the TLS negotiation is completed for the client.

Note: Wireshark displays the Finished message as Encrypted Handshake since, unlike the previous messages, this
message has been encrypted with the just negotiated keys/algorithms.

4. Server response to Client

Change Cipher Spec

Page 7 of 9
The server informs the client that it the messages will be encrypted with the existing algorithms and keys.

The record layer now changes its state to use the symmetric key encryption.

Page 8 of 9
 Finished

Like the Client Finished message but contains a different label (“server finished”). Once the client
successfully decrypts and validates the message, the server is successfully authenticated.

5. Application Data Flow

Once the entire TLS Handshake is successfully completed and the peers validated, the applications on
the peers can begin communicating with each other.