What is the TLS protocol?

Last Updated on March 16, 2022

Most websites secure their content and protect the privacy and integrity of the data exchanged through the internet by using the Hypertext Transfer Protocol Secure (HTTPS). HTTPS or HTTP over TLS is a communication protocol that encrypts the data exchanged between an application and a server (in most cases, the client application is a web browser). Basically, HTTPS is just the HTTP protocol on top of the TLS protocol, which is responsible for transport security.

In the past, only e-commerce and banking websites were using HTTPS to process sensitive data like passwords or credit card information. But, with the evolution of the Internet and the pressing concerns of data privacy, HTTPS became the de-facto web standard to use. This allows protecting all information in transit between the server and the client browser or application. Therefore, for your own security, you should avoid any website that is not using HTTPS. With the evolution of technology, there is no excuse for websites that are still using HTTP instead of HTTPS.

Furthermore, you can see on the browser if the website is using HTTPS or not. Usually, the browser displays a lock icon near the URL of the website.

Now let’s take a look at the element that is responsible for the security aspect of HTTPS: the TLS protocol.

What is the TLS protocol?

Transport Layer Security (TLS) is a cryptographic protocol that uses a combination of symmetric and asymmetric encryption to encrypt the communication channel between 2 computers. It’s the successor of the well known and now deprecated Secure Socket Layer protocol (SSL).

The TLS protocol operates at the presentation layer of the OSI model and therefore relies on a network protocol operating at the transport layer of the OSI model, such as TCP. Most of the time, a TLS session sits on top of a TCP connection. This is usually what happens when you use your web browser to navigate to an HTTPS website. In this scenario, the HTTP protocol is used through the TLS channel, which sits on top of the TCP protocol (i.e. transport layer).

Another variant of the TLS protocol uses the UDP protocol underneath. The standard for this variant is DTLS (Datagram Transport Layer Security).

However, you have to keep in mind that wherever you see the term TLS, it refers to the TLS protocol used on top of TCP transport.

Now, let’s look at the benefits of establishing a secure communication channel with TSL.

The TLS protocol – Client and server authentication

TLS allows both the client and the server to authenticate each other by using public-key cryptography. In a typical scenario, only the server has a certificate. The client verifies the identity of the server after receiving the public key of the server during the TLS handshake.

The certificate validation process does not only check that the server is in possession of the private key. The client also validates that this certificate is issued by a trusted certificate authority (CA) by checking the signature of the authority. In a nutshell, the whole certificate chain has to be verified from the initial server certificate to the root CA. A legit root CA is usually trusted by the operating system of the machine running the browser.

The TLS protocol – Encrypted channel

All information transmitted through a TLS channel is encrypted by a symmetric encryption protocol, such as AES or CHACHA20. The encryption keys are generated at the beginning of the TLS session.

During the TLS handshake, both parties negotiate to select an encryption protocol and a shared session key that will be used for the duration of the session. This procedure represents the key exchange mechanism in the TLS handshake.

The TLS protocol – Message authentication

Before sending a message, the sender computes the message digest with a message authentication algorithm, such as HMAC-SHA256 or AEAD. This message digest is used to validate the integrity of the message. During the TLS handshake, both parties negotiate the message authentication algorithm as well (i.e. cipher suites negotiation or cipher specs negotiation).

Different versions of the TLS protocol

At the time of writing this article, there are 4 versions of the TLS protocol: TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3. A new version of the protocol is usually created by improving the previous version and removing compromised cipher suites.

The security level of a TLS session is strongly related to the security level of the cipher suites used for this session. If there are security flaws in the selected cipher suite, the TLS connection can be considered insecure.

Moreover, because of TLS misconfigurations,  some browsers or servers select a strong cryptographic suite with weak parameters, therefore reducing the level of security of the overall TLS channel.

Based on the PCI DSS recommendation, people should use TLS 1.2 or higher. Basically, TLS 1.0 and TLS 1.1  are both deprecated because they allow the selection of certain cipher suites that are vulnerable to proven security attacks. More precisely, TLS 1.0 is vulnerable to the BEAST attack. The browser exploit against SSL/TLS (BEAST), published in 2011, is an attack that leverages a weakness in the generation of initialization vectors in block ciphers in CBC mode.  

This is what RFC 7525 says about TLS 1.0: 

Implementations SHOULD NOT negotiate TLS version 1.0 [RFC2246]; the only exception is when no higher version is available in the negotiation.

Rationale: TLS 1.0 (published in 1999) does not support many
modern, strong cipher suites. In addition, TLS 1.0 lacks a per-
record Initialization Vector (IV) for CBC-based cipher suites and
does not warn against common padding errors.

Therefore, you should not use TLS 1.0 and 1.1.

What about SSL protocol?

Well, the SSL protocol is the predecessor of the TLS protocol and is deprecated with capital D. It’s not recommended to use any version of the SSL protocol (SSLv2 and SSLv3). SSLv2 is vulnerable to the DROWN attack and SSLv3 is vulnerable to the POODLE attack. Since both versions are insecure, you might as well move directly to TLS 1.2 or TLS 1.3.

The ABC of the TLS protocol cipher suites

On most of the technical documentation about TLS, they talk about the cipher suites. What is the cipher suite? Well, as explained in the previous section, TLS allows communicating parties to perform authentication, message authentication, and channel encryption. These 3 features require cryptographic algorithms and both the client and the server need to be aware of the selected algorithms during a TLS session. The combination of cryptographic algorithms selected for a TLS session is called a cipher suite. There are many combinations possible of course.

Now, let’s take a look at the representation of a cipher suite. Here is an example of a cipher suite available for TLS 1.2:

Example of cipher suite: TLS_ECDHE-RSA-AES128-GCM-SHA256  

The cipher suite text contains information about the authentication mechanism, the key exchange protocol, the message authentication, and the hash functions of the TLS session.

Key exchange mechanism

Example of cipher suite: TLS_ECDHE-RSA-AES128-GCM-SHA256  

The key exchange mechanism in this cipher suite is Elliptic Curve Diffie-Hellman Ephemeral (ECDHE), which is based on ECDH with a generated ephemeral key.  ECDH is a key exchange mechanism that allows the client and the server to agree on a shared secret over an insecure channel. The client and the server use the shared key to derive a symmetric encryption key for the communication channel.

This protocol is a version of the Diffie-Hellman key exchange protocol (DH) based on the elliptic curve cryptographic (ECC). Therefore, each party will have an elliptic curve public-private key-pair in order for the key exchange mechanism to take place. Usually, the server will randomly generate an elliptic curve key pair. Other popular options for the Key exchange protocol in TLS are Ephemeral Diffie-Hellman key exchange (DHE), RSA Key exchange, and Pre-Shared Key (PSK).

Authentication

Example of cipher suite: TLS_ECDHE-RSA-AES128-GCM-SHA256  

 The authentication mechanism in this cipher suite is RSA. In other words, the browser will use RSA to authenticate the server. It also implies that the server has an RSA certificate and shares its public key with clients. These clients will then be able to verify the identity of the server.

NB: I wrote an article about RSA if you want to learn more on this topic.

If the authentication field was set to ECDSA, then the client would use the elliptic curve digital signature algorithm to verify the identity of the server: which implies that the server certificate is based on ECC. ECDSA is newer than the RSA algorithm, it’s the cryptographic algorithm used by Bitcoin.

Encryption

Example of cipher suite: TLS_ECDHE-RSA-AES128-GCM-SHA256  

The encryption protocol in this cipher suite is AES128-GCM.

The  Advanced Encryption Standard (AES) protocol will be used with a 128-bit key to encrypt the communication channel. The block cipher mode of operation is Galois/Counter Mode (GCM)  as specified in the text.

Message authentication

Example of cipher suite: TLS_ECDHE-RSA-AES128-GCM-SHA256 

As explained in RFC 5288, AES-GCM is an authenticated encryption, therefore on top of providing confidentiality, it provides a way to check the integrity and authenticity of the message. Basically, AES-GCM is part of the  Authenticated Encryption with Associated Data (AEAD) algorithms. So, it can be used to authenticate messages as well: this is exactly what will happen in this cipher suite.

Hash function

Example of cipher suite: TLS_ECDHE-RSA-AES128-GCM-SHA256 

The hash function in this cipher suite is SHA256. The secure hash algorithm (SHA) will be used whenever a hash calculation is necessary. In this case, it will mostly be used for key derivation from the master key, since AEAD is already used for message authentication.

Basically, all sections of the cipher suite have their purpose. For example, here is the representation of the same cipher suite with an ECDSA certificate instead of an RSA certificate: TLS_ECDHE-ECDSA-AES128-GCM-SHA256.

TLS 1.3 cipher suites

Since TLS 1.3 uses only strong cipher suites that offer a high level of security, the annotation is slightly different. TLS 1.3 relies only on ephemerals DH key exchange protocols (mostly ECDHE). Basically, both static RSA and static DH key exchanges have been removed. Yes, you’ve read it correctly, RSA key exchange has been removed from TLS 1.3. The main reason is the fact that RSA key exchange does not support ephemeral keys during the key exchange mechanism, therefore it does not offer Perfect Forward Secrecy. Also, RSA key exchange is vulnerable to an exploit called the Bleichenbacher’s CAT.

Furthermore, TLS 1.3 does not specify the certificate type in the cipher suite annotation (i.e RSA, ECDSA). However, ECDSA certificates are recommended in order to provide a high level of security. Therefore, the cipher suite annotation for TLS 1.3 is simplified like TLS_AES_128_GCM_SHA256. (No need to specify the key exchange protocol and certificate type).

The TLS protocol handshake

TLS handshake is the initialization procedure used by the client and the server to establish the TLS session. The goal of this procedure is to negotiate and agree on the cipher suite to use, authenticate each party, and then create a symmetric session key that will be used to encrypt the communication channel.

Now let’s take a look at the TLS 1.2 handshake with no client certificate, which is the typical case when you use your browser to navigate to an HTTPS website: only the server has a certificate. We will first look at the basic RSA key exchange mechanism before explaining one of the Diffie-Hellman key exchange protocol (ECDHE in our case).

NB: TLS 1.3 handshake is different from the previous versions, the number of round-trips between the client and the server have been reduced in TLS 1.3. We will talk about TLS 1.3 handshake in another article.

TLS 1.2 handshake with RSA Key exchange

The following picture gives a step-by-step overview of the RSA key exchange procedure (based on RFC 5246)

Step 1

The client starts the TLS negotiation phase by sending a ClientHello message to the server. The ClientHello message contains a random prime number generated by a secure random number generator on the client-side. Also, this message includes the highest TLS version supported by the client, the cipher suites that are available on the client machine, and the supported compression algorithms. The server needs this information to select a cipher suite and a compression algorithm for the TLS session.

Step 2

When the server receives the ClientHello, it sets the TLS protocol version to the highest version supported by both sides (the client and the server). Furthermore, a cipher suite and a compression algorithm will be selected based on the choices proposed by the client in the ClientHello message. Then, the server will send a ServerHello message to the client, containing all information about the selected TLS version, cipher suite, and compression algorithm.

Step 3

The server sends a Certificate message to the client. This message contains X509 certificate that authenticates the server. The RSA public key of the server is in the Subject public key Info field of the certificate.

Step 4

This is the end of the negotiation phase, so the server sends a ServerHelloDone message to the client.

Step 5

After receiving the Certificate message, the client verifies that the certificate is valid (matching hostname, not expired, not revoked) and signed by a trusted certificate authority (CA).

The client will then send a ClientKeyExchange message to the server. This message contains a pre-master secret generated by the client and encrypted with the server RSA public key.  This pre-master secret will be used in conjunction with the 2 random prime numbers previously generated by the client and server to derive a master secret.

Both sides will use the master secret with pseudo-random functions to compute the session key. The session key is necessary for the symmetric encryption of the TLS channel.

Step 6

The client sends a ChangeCipherSpec message to the server. The goal of this message is to let the server know that all subsequent messages will be encrypted.

Step 7

The client sends an encrypted Finished message to the server. This message includes an HMAC of the handshake messages that will be verified by the server.

Step 8

The server sends a ChangeCipherSpec message to the client to indicate that all messages will be encrypted from this moment.

Step 9

The server sends an encrypted Finished message to the client. This message includes an HMAC of the handshake messages that will be verified by the client. This step marks the end of the handshake and all subsequent messages will be encrypted by a session key.

TLS 1.2 handshake with ECDHE

The TLS handshake with DHE or ECDHE has a couple of extra steps that are not present in the TLS handshake with RSA key exchange. The major difference comes from the fact that in the DHE/ECDHE key exchange mechanism, both the client and the server use ephemeral keys in the negotiation phase of the handshake. These are short-term keys that are usually not saved outside of the process handling the TLS negotiation.

In the RSA key exchange mechanism, a man in the middle (or a government agency) that saves all communications between the server and the client, will be able to decrypt all previous TLS sessions if the private key of the server is revealed. Basically, with RSA key exchange, all your previous TLS sessions are exposed if the RSA private key is compromised.

However, with DHE/ECDHE key exchange mechanism, a man in the middle cannot decrypt the data for previous TLS sessions because these sessions were established with temporary asymmetric keys that are not available anymore: this is the security feature called Forward Secrecy (or Perfect Forward Secrecy). In this case, the long term server private key is just used to sign the DH key exchange messages.

Now, let’s take a look at the TLS 1.2 handshake with ECDHE as the key exchange mechanism and ECDSA as authentication protocol (RFC 4492).

Step 1

The client starts the TLS negotiation phase by sending a ClientHello message to the server. The ClientHello message contains a random prime number generated by a secure random number generator on the client-side. This message includes also the highest TLS version supported by the client, the cipher suites that are available on the client machine, and the supported compression algorithms. The server needs this information to select a cipher suite and a compression algorithm for the TLS session.

Step 2

When the server receives the ClientHello, it sets the TLS protocol version to the highest version supported by both sides (the client and the server). Furthermore, a cipher suite and a compression algorithm will be selected based on the choices proposed by the client in the ClientHello message. Then, the server will send a ServerHello message to the client, containing all information about the selected TLS version, cipher suite, and compression algorithm.

Step 3

The server sends a Certificate message to the client. This message contains an X509 certificate that authenticates the server. The server certificate must contain an ECDSA public key and must be signed with ECDSA by a certificate authority.

Step 4

The server sends a ServerKeyExchange message containing its ephemeral ECDH public key and all information about the elliptic curve parameters used by the server. This message also contains the client and the server’s random numbers. Also, this message is signed with the server ECDSA private key. The client will be able to verify the signature at the reception of the message.

Step 5

This is the end of the negotiation phase, so the server sends a ServerHelloDone message to the client.

Step 6

After receiving the Certificate message, the client verifies that the certificate is valid (matching hostname, not expired, not revoked) and signed by a trusted certificate authority.

The client will also verify the signature of the ServerKeyExchange message. Then, the client generates an ECDH key pair by using the same ECC parameters as the server. Afterward, the client sends a ClientKeyExchange message containing its ECDH public key.  The client and the server will then perform an ECDH operation to compute a pre-master secret, which will be used to derive the session key.

Step 7

The client sends a ChangeCipherSpec message to the server. The goal of this message is to let the server know that all subsequent messages will be encrypted.

Step 8

The client sends an encrypted Finished message to the server. This message includes an HMAC of the handshake messages that will be verified by the server.

Step 9

The server sends a ChangeCipherSpec message to the client to indicate that all messages will be encrypted from this moment.

Step 10

The server sends an encrypted Finished message to the client. This message includes an HMAC of the handshake messages that will be verified by the client. This marks the end of the handshake and all subsequent messages will be encrypted by the session key.

Conclusion

If you are a newbie in the security world, I hope this article gives a good overview of everything that goes underneath when you browse to an HTTPS website. If you are a security or computer science expert, I hope this article could help refresh your memory on this topic.

TLS 1.3 handshake is different from TLS 1.2 handshake. They removed deprecated cipher suites and also simplified the handshake process. For this reason, TLS 1.3 is faster than TLS 1.2. Many servers are already using TLS 1.3 and the adoption rate will increase in the future. Therefore, if you are using TLS 1.2, it’s time to start supporting TLS 1.3. And for those who are still using TLS 1.0 and TLS 1.1, well, it seems like you like flirting with danger, what are you waiting for to upgrade?