TLS/SSL Explained – Establishing a TLS Connection, Part 5

In part 1, 2, 3 and 4 of this series we looked at What is TLS/SSL?, took a brief look at the History of TLS and SSL, TLS/SSL terminology and basics and TLS/SSL Certificates. In this fifth part in the series, we will be looking at establishing a TLS connection.

To get a better understanding of the TLS protocol, we will now see what exactly takes place for a secure connection to be established.

The most important process of the connection establishment is the so called “Handshake”. During the Handshake, server and client will exchange important information regarding the properties under which the connection will be established.

During the Handshake we will see how a hybrid of asymmetric and symmetric encryption is used in order to ensure security.

For this article we will refer to a browser as the Client. In the following example, Diffie-Hellman is used for the key exchange.

Client Hello

A standard negotiation between client-server (handshake) starts off with a Client Hello message.

The client, sends a Client Hello to the server and includes the following.

Client hello


The client will send a list of all the SSL/TLS protocol versions it supports, with the preferred one being first on the list. The preferred one is usually, and should be, the latest available version.


A 32-byte random data of which 4 bytes represent the client’s current datetime (in epoch format) and the remaining 28 bytes, a randomly generated number. The Client’s random and Server’s random will later be used to generate the key which the data will be encrypted with.


This is the session id which will be used for the connection. If the session_id is not empty, the server will search for previously cached sessions and resume that session if a match is found.


This is the method that is going to be used for compressing the SSL packets. By using compression, we can achieve lower bandwidth usage and therefore, faster transfer speeds. Later on this article we will see why using compression is risky.


Cipher suites are combination of cryptographic algorithms which are used to define the overall security of the connection to be established. Typically, each cipher suite contains one cryptographic algorithm for each of the following: Key Exchange, Authentication, Bulk (data) Encryption and Message Authentication.

A sample cipher suite is the following:

Let’s break this down so that it makes more sense.

  • TLS is the protocol being used
  • ECDHE is the key exchange algorithm (Elliptic curve Diffie–Hellman)
  • ECDSA is the authentication algorithm (Elliptic Curve Digital Signature Algorithm)
  • AES_128_GCM is the data encryption algorithm (Advanced Encryption Standard 128 bit Galois/Counter Mode)
  • SHA256 is the Message Authentication Code (MAC) algorithm (Secure Hash Algorithm 256 bit)

Here’s what an actual Client Hello looks like in a Wireshark capture.

Wireshark capture

The client can request additional functionality for the connection and this can be done via “extensions”. If the server cannot provide the additional functionality, then the client can abort the handshake if needed.

Server Hello

Server Hello

After the server receives the Client Hello, the second step will be to reply with a Server Hello. If it finds an acceptable set of algorithms in Client’s request, it will respond by accepting those options and provide its certificate. If the server does not meet the requirements of the Client it will respond with a handshake failure message.

The server, sends a Server Hello to the client and includes the following.


The server will (not blindly) select the Client’s preferred version of SSL/TLS protocol.


32 bytes of random data, out of which 4 bytes represent the server’s current datetime (in epoch format), and the rest 28 bytes is a randomly generated number will be sent to the client. The Server’s random and Client’s random will later on be used to generate the key with which the data will be encrypted.


This is the session id which will be used for the connection. If the session_id sent by the Client is not empty, the server will search for previously cached sessions and if a match is found, that session id will be used, thus resuming. If the session_id is empty, a new session will be created for the connection.


If supported, the server will agree on the Client’s preferred compression method.


If supported, the server will agree on the Client’s preferred cipher suite.


The signed certificate of the server which proves the identify it’s to the client. It also contains the public key of the server.

Client Certificate (optional)

Not often, the server may require the client to be authenticated with a Client Certificate as well. In cases like this the client will provide its signed certificate to the server.

Server Key Exchange

The server key exchange message is sent only if the certificate provided by the server is not sufficient to allow the client to exchange a pre-master secret. (This is true for DHE_DSS,DHE_RSA and DH_anon)

Server Hello Done

This is sent to the client as a confirmation that the Server Hello message is completed.

The following is what a Server Hello looks like in a Wireshark capture.

server hello wireshark capture


Client Key Exchange

Key Exchange

The Client Key Exchange message is sent right after the Server Hello Done is received from the server. If the server requests a Client Certificate, the Client Key Exchange will be sent after that.

During this stage, the client will create a pre-master key.

Pre-Master Secret

The pre-master secret, is created by the client (the method of creation depends on the cipher suite that will be used) and then it is shared with the server.

Before sending the pre-master secret to the server, the client encrypts it using server’s public key which was extracted from the certificate provided by the server. This means that only the server can decrypt the message since asymmetric encryption is being used for the pre-master secret exchange.

The following is what the key-exchange looks like in a Wireshark capture (using DH).

key exchange

Master Secret

After the server receives the pre-master secret key, it uses its private key to decrypt it. Now both client and server will compute the master-secret key based on the random values exchanged earlier (ClientRandom and ServerRandom) using a Pseudorandom Function (PRF). A PRF is a function used to generate arbitrary amounts of pseudorandom data.

master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47];

The master-secret key, which is 48 bytes in length, will then be used by both client and server to symmetrically encrypt the data for the rest of the communication.

Each of the parties, Client and Server, will create 3 set of keys.

  • client_write_MAC_key – Authentication and Integrity check
  • server_write_MAC_key – Authentication and Integrity check
  • client_write_key – Message encryption using symmetric key
  • server_write_key – Message encryption using symmetric key
  • client_write_IV – Initialization Vector used by some AHEAD ciphers
  • server_write_IV – Initialization Vector used by some AHEAD ciphers

Both Client and Server will use the master secret to generate the sessions keys which will be to encrypt/decrypt the data.

Change Cipher-Spec

Change Cypher Spec

Change Cypher Spec

At this point, both the Client and the Server are ready to switch to a secure, encrypted environment. The Change Cipher Spec protocol is used to change the encryption being used by the client and server. Any data being exchanged between the two parties will now be encrypted with the symmetrical shared key they have.

This is what the Change Cipher Spec looks like in a Wireshark capture.

 Change Cipher Spec Protocol


The last message of the handshake process and first encrypted one in the secure connection is Finished, which is exchanged by both parties.

Application Data

Application Data

To recap, the following illustrates a typical handshake.

typical handshake

Share this post
Agathoklis Prodromou Web Systems Administrator/Developer

Akis has worked in the IT sphere for more than 13 years, developing his skills from a defensive perspective as a System Administrator and Web Developer but also from an offensive perspective as a penetration tester. He holds various professional certifications related to ethical hacking, digital forensics and incident response.
  • Hello, I wonder if the “session key” and the “write key” is the same thing ?
    and another question please, is Master Secret has the SAME value in the two sides (client & server).

  • “In the following example, Diffie-Hellman is used for the key exchange.”

    The key exchange illustrated here in this article is RSA and not Diffie-Hellman.

    • Hi สุรศักดิ์ ซีไอเอสเอสพี. It might be adjusted a bit so that its not confusing.

  • It would be interesting to comment about the vulnerabilities of TLS regarding end to end secure channel vs point to point secure channel. Particularly, how is the handshake between a routing point and the next hop and when the data is kept in plain text.

  • Hello. Excellent explanation. I just have one quick query. How is the Master Key generated ? and how is it related to the Pre Master Secret ?

    The article says “Now both client and server will compute the master-secret key based on the random values exchanged earlier (ClientRandom and ServerRandom) using a Pseudorandom Function (PRF). ”

    So does this mean
    “Now both client and server will compute the master-secret key based on the ”Pre Master Secret +” random values exchanged earlier (ClientRandom and ServerRandom) using a Pseudorandom Function (PRF). “

    • Hello,

      Thanks for your comment!

      Yes that is correct. For the Master Secret to be computed the Pre-Master-Secret + random values exchanged between Client+Server are used in the PRF (Pseudo Random Function):

      master_secret = PRF(pre_master_secret, “master secret”, ClientHello.random + ServerHello.random) [0..47];

      This will generate the 48 byte long Master Secret.

  • Hello,
    Very nice explanation. Is it possible to “install” the servers public key in a client, so it does not have to trust the certificate autority (if the certificate is self-signed). Can that be part of this protocol, like the client saying “I already have your public key, lets just agree on the other things”?

    Thanks in advance.

    • Hi and thanks for your comment.

      You cannot skip parts of the handshake process, for instance NOT have the server send their public cert. Also whether you have “stored” the server’s public certificate or not is irrelevant to the C.A “trust” validation process. If you want the client to trust a self-signed certificate then you need to create your own CA/Root Authority and then create and sign a new certificate using the CA’s private key and CA’s certificate. Then all you have to do is import the CA’s public key into the trusted Root Authorities of the client you are using (commonly a browser). This will result in your self-signed cert being treated as any other trusted one. The process is trivial, you can find plenty of articles online on how to do this.

  • Excellent explanation,
    I have one question that as you explained at the time of select cipher suite, for example the server select following cipher suite:


    Here, according to you RSA is authentication algorithm ( explained in client hello).

    But I did not understand where it is used during the whole process.

    Can you please explain?

    • Thank for your comment! The RSA here refers to the type of algorithm the public key (certificate) of the other party ideally should be in order to proceed (I say ideally because the client will send multiple ciphersuites and the authentication algorithm might vary). For example during a connection the Client might ask the server to negotiate TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as per your example. If the server cannot fulfill the request of the client, meaning providing a public key of RSA type then the handshake will fail and the connection will close. If the Client requested TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 then the server would need to provide a ECDSA certificate. Both (RSA/ ECDSA) are used for authentication (simply put, checking if a certificate is valid). I hope its clear now!

  • Leave a Reply

    Your email address will not be published.