When it comes to network security, I keep hearing TLS (and sometimes SSL). but what is TLS and how does it work?
In this post, I’ll share my understanding about this protocol, more specifically I concentrate on the TLS handshake process in a secure connection.

TLS stands for Transport Layer Security is a cryptographic protocol designed to provide communications security over a computer network. This protocol is being used through lots of applications but the main one we can say it’s the core of HTTPS.
In the OSI model, you can argue that TLS sits in the layer 6 which is the Presentation.

OSI Layers

Are TLS and SSL same?

Sometimes people refer to TLS and SSL interchangeably, but they are not exaxtly same!
SSL is a predecessor protocol for secure network which supports older cryptographic algorithm that potentially have security vulnerabilities. SSL was developed by Netscape. TLS was an evolusion of SSL with the aim to address those vulnerabilities, Upon releasing TLS 1.0 protocol, the name was changed to indicate there’s no affiliation with Netscape.
Other than security improvement, another major difference between SSL and TLS is the speed of handshake, as TLS has a fewer steps in the handshake process, it can perform faster. The latest TLS vesrion is 1.3 which was introduced on 2018.

TLS Handshake

TLS Handshake The handshake is a protocol between client and server which init the secure communication. During handshake the parties authenticate, agree on the encryption algorithms and establish a secure channel for their connection.
TLS versions have different handshake process. For example, TLSv1.3 simplifes the handshake into fewer steps which led to a better performance whereas TLSv1.2 involves more back and forth between server and client.

Let’s take a look at the two last TLS protocols:

TLS 1.2 Process

There are 4 steps involve in TLS v1.2 handshake:

  1. Client Hello
  2. Server Hello
  3. Client Key Exchange, Change Cipher Spec and Finished
  4. Server Change Cipher Spec and Finished

1. Client Hello

In the first step, the client initiates a hello message to the server. Hello message contains TLS version, a list of cipher suites and random number. Basically in this message, the client advertises its capabilities to the server.
A cipher suite is a set of cryptographic algorithms used to secure a network connection. Think of it as a recipe for building a secure communication channel. The random number which also known as Client Random is a prime number that randomly picked. This number is needed in the next steps.

2. Server Hello

The server receives the client request and respond with Server Hello message. In this step, server confirms the TLS version that supports and selects a cipher suite. Server also creates a random number which known as Server Random. Another data that shares in this step is the Server Certificate.
Server certificates is needed so the client could authorize the server. All trusted SSL certificates are issued by a Certificate Authority (CA), which is a company that has been approved to issue digital certificates. Client needs to make sure the certificate provided by server is a valid one.
Based on the selected cipher suite, the server may send additional information as Server Key Exchange. Some algorithms like Diffie-hellman (DH) need this information for encryption logic.

3. Client Key Exchange, Change Cipher Spec and Finished

When the client receives the server’s hello message, It verifies its certificate. If the certificate is not valid, the handshake fails and connection terminates. Client also extracts the public key from the certificate.
To set up secure communication using symmetric encryption, the client first generates a secret piece of data called a pre-master key. In the case of RSA, the client securely transmits this pre-master key to the server by encrypting it with the server’s public key, which was previously shared.
If the cipher suite is based on DH, this message also contains DH’s public key. Next message is Change Cipher Spec which indicates to the server that client is ready to start encryption mode. Finally Client sends a Finish message to completes its role in the handshake.

4. Server Change Cipher Spec and Finished

In this step, both the client and server have: server random, client random and pre-master key. They use these data to create the master key which will be used for symmetric encryption through the continues of the connection.
You may wonder why the need this whereas they could just use asymmetric encryption (public/private keys)?! The answer is efficiency!
symmetric encryption is much more efficient and therefore faster in transferring data.
Server let the client know that is ready for encryption mode by sending change cipher spec message. Server then sends a finished message to completes the handshake.

TLS 1.3 Process

TLS v1.3 was introduced to address few issues that existed in TLS v1.2. It offers:

  • Faster handshake
  • Fewer Cipher Suite (Down to 5 from 37)
  • Improvement on security with new encryption algorithms
  • Support for 0-RTT (Zero Round Trip Time)

TLS 1.3 Handshake has fewer steps which is as follow:

  1. Client Hello, Key Share
  2. Server Hello, Key Share, Certificate, Finished

1. Client hello, Key Share

In TLS 1.3, Client starts the handshake by providing more information to server. As mentioned the TLS 1.3 only supports 5 cipher suites, hence client can share the key pair for each of the ciphers in the hello message.

2. Server Hello, Key Share, Certificate, Finished

Using the key that client shared plus the server own key, The server is able to calculated a symmetric key for encryption which is also known as session key.
In the server hello, the server choose the cipher and shares its key with the client so that client can generates the same session key. The server also sends the certificate so the client could veritfy that it is legit. The certificate that is being sent will be encrypted using the session key.
And at last, The server sends a finished message to complete the handshake and let the client know that is ready for encryption mode.

Wireshark Example

Now, let’s dive into a network capture from Wireshark to better understand how handshake messages look like in action. I use Google Chrome for my test. Chrome default behaviour uses latest version of TLS which currently is the version 1.3. You can change the default TLS vesrion when you set these two command line arguments:

  • –ssl-version-max: Specifies the maximum SSL/TLS version (“tls1.2” or “tls1.3”).
  • –ssl-version-min: Specifies the minimum SSL/TLS version (“tls1.2” or “tls1.3”).

For example, if you want to force Chrome browser to not communicate any protocol above TLS 1.2 (Which of course not recommended!), you run this command:

google-chrome --ssl-version-max=tls1.2

OK, Now I enter my website address when Chrome set to TLS 1.2 and TLS 1.3.
From the first look, It becomes clear TLS 1.3 has less handshake steps than TLS 1.2.

Wireshark TLS 1.2 and 1.3 first look

Client Hello

The client hello message for TLS 1.2 does have few dozens fields.

TLSv1.2 Record Layer: Handshake Protocol: Client Hello
    Content Type: Handshake (22)
    Version: TLS 1.0 (0x0301)
    Length: 202
    Handshake Protocol: Client Hello
        Handshake Type: Client Hello (1)
        Length: 198
        Version: TLS 1.2 (0x0303)
        Random: dfce0524cbf943d7f4dbe7e529340365522aa35017bc3e0eb12f8d82395cc987
        Session ID Length: 0
        Cipher Suites Length: 26
        Cipher Suites (13 suites)
        Compression Methods Length: 1
        Compression Methods (1 method)
        Extensions Length: 131
        Extension: Reserved (GREASE) (len=0)
            Type: Reserved (GREASE) (39578)
            Length: 0
            Data: <MISSING>
        Extension: server_name (len=25)
            Type: server_name (0)
            Length: 25
            Server Name Indication extension
                Server Name list length: 23
                Server Name Type: host_name (0)
                Server Name length: 20
                Server Name: emadkhezri.github.io
        ...

TLS handshake is wrapped inside a TLS record protocol. The first 3 fields defines the header for TLS record protocol which basically instructs what to follow in the message.

  • Content Type: The TLS record protocol can wrap four types of message: handshake, alert, change cipher spec and application data.
  • Version: This might seems confusing but this is the version of TLS record protocol. This advertising version 1.0 of the record layer protocol but as you’ll see, the handshake itself is version 1.2. This is necessary for backwards compatibility and supporting old proxies.
  • Length: This fields tells the number of bytes that the actual handshake message is. This is necessary for server to interpret the message properly.

The rest is the payload of the actual wrapped TLS client hello message. The basic fields of handshake message are:

  • Handshake Type: There are 10 types of handshake message.
    • hello request
    • client hello
    • server hello
    • certificate
    • server key exchange
    • certificate request
    • server hello done
    • certificate verify
    • client key exchange
    • finished
  • Length: The length of handshake message in bytes.
  • Version: The version of the actual TLS message that client hello message structs with.
  • Random: The client random which is 32 bytes.
  • Session ID Length: If the client starts a handshake on an already established conneciton, it includes a session ID that’s assoicated with the previous negotiated handshake. If there’s no session, the length is zero.
  • Cipher Suites Length: The number of bytes for the list of cipher suites.
  • Cipher Suites: The list of cipher suites which client sends as part of the client hello.
  • Compression Method: Originally, TLS was designed to handle both encryption and compression. Consequently, a compression method field was included in the protocol. However, this feature has been never used in practice. The compression method field is always set to a single value of 00, indicating No Compression.

Extensions

The previous fields are included in the TLS Standard according to RFC 2246, however the designers wanted to have more flexibility on the protocol in the future, hence they introduced extensions.
TLS Extensions are used to enhance the protocol’s capabilities. Each extension includes a length field indicating its size, followed by the extension data. Let’s take a closer look at a couple of these extensions.

  • Grease: This stands for Generate Random Extensions and Sustain Extensibility. This extension is failsafe check and is effectively always presented. It tells the server that the client is able to defend against renogotiation flaw.
  • Server Name Indication (SNI): This extension helps the server to know what host name is trying to connect to it. This can be important if a website hosts multiple domins.
  • Application Layer Protocol Negotiation (ALPN): This extension used for determining which application protocol (like HTTP/1 or HTTP/2) is going to be used within a secure connection.
  • Signature Algorithms Cert: This extension was added to allow implementations which support different sets of algorithms for certificates and in TLS itself to clearly signal their capabilities.

Server Hello

Okay, let’s check out what a Server Hello message looks like in Wireshark.

    TLSv1.2 Record Layer: Handshake Protocol: Server Hello
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 80
        Handshake Protocol: Server Hello
            Handshake Type: Server Hello (2)
            Length: 76
            Version: TLS 1.2 (0x0303)
            Random: 66c1bf699ca1ed0fbfbeb1af70c1fcb8c3020894bb1e9dd4444f574e47524401
            Session ID Length: 0
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
            Compression Method: null (0)
            Extensions Length: 36
            Extension: server_name (len=0)
            Extension: extended_master_secret (len=0)
            Extension: renegotiation_info (len=1)
            Extension: ec_point_formats (len=2)
            Extension: session_ticket (len=0)
            Extension: application_layer_protocol_negotiation (len=5)
            Extension: status_request (len=0)
                Type: status_request (5)
                Length: 0
            [JA3S Fullstring: 771,49199,0-23-65281-11-35-16-5]
            [JA3S: a885fb01204bc11cc58efc02fe640899]

Similar to client hello, the actual handshake is wrapped inside a TLS record protocol. The TLS record protocol has these fields:

  • Content Type: The record type is a handshake same as client hello.
  • Version: In oppose to Client Hello, the TLS record version is match with Handshake. In here, basically server tells the client that it supports the requested TLS version which is v1.2.
  • Length: This fields tells the number of bytes that the actual handshake message is.

Let’s see few of the important fields on the actual handshake message:

  • Handshake Type: the handshake type is server hello obviously.
  • Random: This field has the server random value which is necessary for a handshake encryption.
  • Version: The choosen TLS version by the Server.
  • Cipher Suite: The choosen cipher suite by the Server from the list of Cipher Suites.

Certificate

Certificate is another handshake message that server sends to client. The structure of this handshake message is as follow:

TLSv1.2 Record Layer: Handshake Protocol: Certificate
    Content Type: Handshake (22)
    Version: TLS 1.2 (0x0303)
    Length: 3094
    Handshake Protocol: Certificate
        Handshake Type: Certificate (11)
        Length: 3090
        Certificates Length: 3087
        Certificates (3087 bytes)

The message contains:

  • Handshake Type: The message handshake type is Certificate.
  • Certificates Length: The length of certificate in bytes.
  • Certificates: The actual certificate data which the server sends to the client.

Server Key Exchange

This message sends from Server to Client because the choosen Cipher is Diffie-Hellman. For this algorithm, the server requires to exchange its server key with client. Here is the message structure for Server Key Exchange.

TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange
    Content Type: Handshake (22)
    Version: TLS 1.2 (0x0303)
    Length: 300
    Handshake Protocol: Server Key Exchange
        Handshake Type: Server Key Exchange (12)
        Length: 296
        EC Diffie-Hellman Server Params

Server Hello Done

This handshake message indicates the end of the server hello communication.

TLSv1.2 Record Layer: Handshake Protocol: Server Hello Done
    Content Type: Handshake (22)
    Version: TLS 1.2 (0x0303)
    Length: 4
    Handshake Protocol: Server Hello Done
        Handshake Type: Server Hello Done (14)
        Length: 0

This message doesn’t have a lot of fields.

Client Key Exchange

As the Cipher suite sets to ECDH (EC Diffie-Hellman), there’s an step which client share the diffie-hellman public key with the server.

TLSv1.2 Record Layer: Handshake Protocol: Client Key Exchange
    Content Type: Handshake (22)
    Version: TLS 1.2 (0x0303)
    Length: 37
    Handshake Protocol: Client Key Exchange
        Handshake Type: Client Key Exchange (16)
        Length: 33
        EC Diffie-Hellman Client Params
            Pubkey Length: 32
            Pubkey: a52baa1c105dfb8417fcc2f0bcaba729f95f651e5258a129c59d7ecf83957818
  • EC Diffie-Hellman Client param: This field includes the public key length and the data that will be send to client.

Client Change Cipher Spec

At this point, client tells the server that its in the symmetric encryption mode.

TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
    Content Type: Change Cipher Spec (20)
    Version: TLS 1.2 (0x0303)
    Length: 1
    Change Cipher Spec Message

Server Change Cipher Spec

This is the message from the server to the client to indicate symmetric encryption is active. The message is similar to what client sends:

TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
    Content Type: Change Cipher Spec (20)
    Version: TLS 1.2 (0x0303)
    Length: 1
    Change Cipher Spec Message

And finally … Application Data

At previous step the handshake is completed, following that all the encrypted message are transferred under Application Data type.

TLSv1.2 Record Layer: Application Data Protocol: http2
    Content Type: Application Data (23)
    Version: TLS 1.2 (0x0303)
    Length: 94
    Encrypted Application Data: 00000000000000013aa92f8cba5776c88d840044d71dfdfa13b5239a7dd13efb27f11e26…
    [Application Data Protocol: http2]

The main fields are:

  • Length: The size of the application data in bytes.
  • Encrytped Application Data: As the name identifies, it’s the encrypted data.
  • Application Data protocol: What protocol is the encrypted message data is coming from. In this case http2.

And that is basically my understanding of TLS Handshake. I hope this blog post has provided you useful information as well. Feel free to share your thought with me.