Transport Layer Security (TLS)

Transport Layer Security (TLS) is a security protocol that helps in the establishment of secure and encrypted communication between two hosts, for example, between a client and a server. When a client needs to establish a secure connection with the server, it will perform a TLS handshake to establish communication. Before diving into the TLS handshake process, we first need to understand the concept of TLS cipher suites.

TLS Cipher Suites

A TLS cipher suite comprises a set of cryptographic algorithms that determine how data will be secured during a TLS session. It specifies the protocol, key exchange method, authentication process, encryption algorithm, and message authentication codes that both the client and server will use to establish communication.

• Protocol — This part of the cipher suite will determine the protocol and version that a client and server be using for this communication.
  For example — TLS 1.3, TLS 1.2, TLS 1.1, TLS 1.0.
• Key Exchange Algorithm — This part of the cipher suite determines how the client and server will securely exchange encryption keys.
  For example — RSA(Rivet-Shamir-Adleman), DH(Diffie-Hellman), ECDH (Elliptic Curve Diffie-Hellman), DHE(Diffie-Hellman Ephemeral), ECDHE(Elliptic Curve Diffie-Hellman Ephemeral).
• Authentication Algorithm — This component ensures that the client and server will able to verify each other identities.
  For example — RSA(Rivet-Shamir-Adleman), and ECDSA(Elliptic Curve Digital Signature Algorithm).
• Cipher or Bulk Encryption Algorithm — This component will be used to encrypt and decrypt the data transmitted between the client and the server.
  For example — AES(Advanced Encryption Standard), Camellia, DES(Data Encryption Standard), RC4, RC2.
• Message Authentication Code (MAC) Algorithm — This component will ensure the integrity of the data by detecting any unauthorized changes using transmission.
  For example — SHA(Secure Hash Algorithm), and MD5(Message Digest).

An example of a Cipher Suite of a website is shown below:

TLS_AES_128_GCM_SHA256 (0x1301)

When we examine the example above, we can observe the presence of the protocol (TLS), bulk encryption algorithm (AES_128_GCM), and message authentication code (SHA256). However, it is worth noting that this suite does not include any key exchange or authentication algorithms. In such cases, the server and client will default to using the RSA algorithm.

Figure 1: SSL Labs Report of a website

TLS Handshake

As we discussed the cipher suites above, which are an essential part of the TLS handshake, let’s dive deeper into the TLS handshake process.

Figure 2: TLS Handshake [Source: Nokia]

Step 1 (Client Hello): During the initial step, the TLS client sends a client hello message containing the following information:

1. Supported version of TLS
2. Cipher Suites supported by the client

Once this message reaches the TLS server, the server will select one of the cipher suites from the list of those it supports.

For example: TLS_ECDHE_RSA_AES128_GCM_SHA256

Step 2: After the TLS server determines which cipher suite should be used for secure communication with the client, it proceeds to the second step of the TLS handshake.

• Server Hello Message: The server will send the “Server Hello” message to the client. The message contains some information:
  — Acknowledgement of the “Client Hello” message.
  — Include some important information for establishing secure communication like the chosen cipher suite and other configuration details.
• Server Certificate: Along with the “Server Hello” message, the server sends its digital certificate. This certificate contains the public key of the server and the client will use this public key to encrypt data sent to the server.
• Hello Done Message: After sending all the important information used for this handshake, the server will send the “Hello Done” message to signal the client that it has completed its part of the handshake. The client will proceed with the next steps of the handshake.

Step 3 (Client Computation): Once the client receives all the information from the server it will do the following:

• Certificate Verification: The first critical task for the client is to validate the authenticity and trustworthiness of the server’s certificate, using the RSA algorithm specified in the selected cipher suite. This process ensures that the server, with which the client intends to communicate, is indeed the entity it claims to be.
• Generating Pre-Master Key: Once the client has verified the server’s certificate, it will proceed to generate the “Pre-Master Key”. The Pre-Master Key is a random secret generated using the server’s public key, random data sent by the server, session IDs, and diffie-hellman algorithm.

Step 4 (Key Exchange): The client uses the generated Pre-Master Key in the previous step (Step 3), and will perform additional computations to generate a symmetric key for bulk data encryption. This symmetric key will be used for encrypting and decrypting the actual data during the TLS session. The encryption technique used, such as AES (Advanced Encryption Standard) or DES (Data Encryption Standard), is determined by the chosen cipher suite during the handshake.

• Key Exchange: In this process, the client encrypts the “Pre-Master Key” using the server’s public key, which was shared during Step 2. This encrypted message is then sent to the server. Additionally, the client transmits the generated ephemeral public key, used in the Diffie-Hellman Algorithm (specifically ECDHE), as defined in the selected cipher suite, to be used in server computations.
• Change Cipher Specification: In this step, the client will notify the server that it will be switching to symmetric encryption.
• Client Finished: A message is sent by the client that the client has finished all the transactions of the handshake to establish secure communication.

Step 5 (Server Computation): Once the server receives the keys sent by the client, it decrypts the message using its private key. This allows it to obtain the same “Pre-Master Key” generated by the client and the ephemeral public key of the client, which is used in the Diffie-Hellman Algorithm. After performing calculations with the Diffie-Hellman Algorithm(ECDHE) and applying the selected bulk encryption algorithm, the server generates the same symmetric key as the client. This symmetric key will be used for symmetric encryption of bulk data. The key exchange in the TLS handshake uses asymmetric encryption. Once the symmetric key is generated, the server sends two messages to the client:

• Change Cipher Specification: This message will notify the client that the server will switch to the new symmetric encryption for secure communication. From this point forward, the data exchanged between the client and server will be encrypted using the symmetric key.
• Server Finished: This message signifies the server’s completion of the handshake. It includes verification of prior handshake messages using MAC (SHA256) specified in the selected cipher suite, ensuring the integrity of the communication and confirming that both client and server have successfully established a secure connection.

Step 6: After the handshake is successfully completed between the client and server, they can securely communicate over the channel, using symmetric encryption for their interaction.

In conclusion, we observe how cipher suites are used in the TLS handshake, we utilize both asymmetric and symmetric encryption in the TLS handshake process. Asymmetric encryption is used for the key exchange, while symmetric encryption is used for secure data transfer.