TLS Security 5: Establishing a TLS Connection

The process of establishing a secure SSL/TLS connection involves several steps. SSL/TLS security protocols use a combination of asymmetric and symmetric encryption. The client and the server must negotiate the algorithms used and exchange key information.

For the purpose of explaining this complex process, we use a TLS 1.2 connection, not the most recent TLS 1.3 protocol. The process used in TLS 1.2 was almost the same for all previous versions of SSL/TLS. However, it was greatly simplified in the latest version of Transport Layer Security.

The most important part of establishing a secure connection is called the handshake. During the TLS Handshake, the server and the client exchange important information used to determine connection properties. This example is based on a web browser handshake, but the same applies to all other SSL/TLS handshakes.

Step 1: Client Hello (Client → Server)

Client hello

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

Client Version

The client sends a list of all the TLS/SSL protocol versions that it supports with the preferred one being first on the list. The preferred one is usually the latest available version. For example, TLS 1.2 has a client_version 3,3. This is because TLS 1.0 is treated as a minor revision of Secure Sockets Layer (SSL 3.0), so TLS 1.0 is 3,1, TLS 1.1 is 3,2, and so on.

Client Random

This is a 32-byte random number. The client random and the server random are later used to generate the key for encryption.

In the original TLS 1.2 specification, the first 4 bytes were supposed to represent the current date and time of the client (in epoch format) and the remaining 28 bytes was supposed to be a randomly generated number. However, IETF later recommended against it.

Session ID

This is the session id to be used for the connection. If the session_id is not empty, the server searches for previously cached sessions and resumes that session if a match is found.

compression_methods

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

Cipher suites are combinations of cryptographic algorithms. Typically, each cipher suite contains one cryptographic algorithm for each of the following tasks: key exchange, authentication, bulk (data) encryption, and message authentication. The client sends a list of all the cipher suites that it supports in order of preference. This means that the client would ideally prefer the connection to be established using the first cipher suite sent.

Cipher suites are identified by strings. A sample cipher suite string is: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256. This string contains the following information:

  • 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)

Compression Methods

This is a list of method that is going to be used for compressing data (before encrypting it). If you use compression, you can lower bandwidth usage and speed up transfers. However, compression is risky and recommended against: see information on CRIME and BREACH attacks.

Extensions

The client can request additional functionality for the connection. This can be done via extensions such as supported groups for elliptic curve cryptography, point formats for elliptic curve cryptography, signature algorithms, and more. If the server cannot provide the additional functionality, the client may abort the handshake if needed.

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

Wireshark capture

Step 2: Server Hello (Server → Client)

Server Hello

After the server receives the Client Hello, it replies with a Server Hello. A Server Hello may either contain selected options (from among those proposed during Client Hello) or it may be a handshake failure message.

Server Version

The server selects the preferred version of the SSL/TLS protocol from among those presented by the client.

Server Random

This is a 32-byte random number. The server random and the client random are later used to generate the encryption key.

In the original TLS 1.2 specification, the first 4 bytes were supposed to represent the current date and time of the client (in epoch format) and the remaining 28 bytes was supposed to be a randomly generated number (just like in the case of Client Random). However, IETF later recommended against it.

Session ID

If the client Session ID was not empty, the server searches for previously cached sessions and if a match is found, that session ID is used to resume the session. If the client Session ID was empty, a new session may be created by the server and sent in the server Session ID.

Cipher Suites

The server selects the cipher suite from among Cipher Suites sent in the Client Hello.

Compression Methods

The server selects the compression method from among Compression Methods sent in the Client Hello.

Step 3: Server Certificate (Server → Client)

The server now sends a signed TLS/SSL certificate that proves its identity to the client. It also contains the public key of the server.

Step 4: Client Certificate (Client → Server, Optional)

In rare cases, the server may require the client to be authenticated with a client certificate. If so, the client provides its signed certificate to the server.

Step 5: Server Key Exchange (Server → Client)

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

Step 6: Server Hello Done (Server → Client)

The server sends this to the client to confirm that the Server Hello message is finished.

This is what a Server Hello looks like in a Wireshark capture.

server hello wireshark capture

SSL TLS

Step 7: Client Key Exchange (Server → Client)

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 is sent after that. During this stage, the client creates 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) and then shared with the server.

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

This is what the key exchange looks like in a Wireshark capture (using Diffie–Hellman).

key exchange

Master Secret

After the server receives the pre-master secret key, it uses its private key to decrypt it. Now, the client and the server compute the master secret key based on random values exchanged earlier (Client Random and Server Random) 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.

The client and the server create a set of 3 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 data.

Step 8: Client Change Cipher Spec (Client → Server)

At this point, the client is ready to switch to a secure, encrypted environment. The Change Cipher Spec protocol is used to change the encryption. Any data sent by the client from now on will be encrypted using the symmetric shared key.

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

 Change Cipher Spec Protocol

Step 9: Client Handshake Finished (Client → Server)

The last message of the handshake process from the client signifies that the handshake is finished. This is also the first encrypted message of the secure connection.

Change Cypher Spec

Step 10: Server Change Cipher Spec (Server → Client)

The server is also ready to switch to an encrypted environment. Any data sent by the server from now on will be encrypted using the symmetric shared key.

Step 11: Server Handshake Finished (Server → Client)

The last message of the handshake process from the server (sent encrypted) signifies that the handshake is finished.

Change Cypher Spec

To recap, the following illustrates a typical handshake.

typical handshake

The TLS Handshake in TLS 1.3

In TLS 1.2 and earlier, the TLS handshake needed two round trips to be completed. The first round trip was the exchange of hellos and the second one was the key exchange and changing the cipher spec. In TLS 1.3, this process is streamlined and only one round trip is needed. TLS 1.3 also no longer supports TLS compression.

TLS connection

In TLS 1.3, when the client sends its hello, it immediately guesses the key agreement protocol that the server will most likely select. At the same time, it shares its key using the guessed protocol. The server’s hello message also contains the shared key, the certificate, and the server finished message. There is no need for cipher change because after the exchange of hellos both parties already have all that they need to encrypt communication.


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).
    thanks.

  • “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:

    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

    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!

  • Excellent article. I finally understood how the handshake is kept secure. Thanks Akis

  • Leave a Reply

    Your email address will not be published.