Learnitweb

TLS Handshake process

—

by

Editorial Team
in

1. Introduction

A TLS handshake is the first step that starts the a TLS communication session. During a TLS handshake, the two parties in the communication exchange acknowledgement messages, verify each other, agree on the cryptographic algorithms to be used in communication and agree on session keys.

SSL was replaced by TLS (Transport Layer Security), SSL handshakes are now known as TLS handshakes.

During TLS handshake the communication parties do the following:

  • Specify the TLS version (TLS 1.0, 1.2, 1.3 etc.) to be used
  • Agree on the cipher suites they will use
  • Authenticate the identity of the server via the server’s public key and the SSL certificate authority’s digital signature
  • Generate session keys to be used in symmetric encryption after the TLS handshake

TLS handshake are a series of messages exchanged between a client and a server.

2. When does a TLS handshake kicks off?

A TLS handshake begins whenever a resource is accessed over HTTPS. For example, when a user requests a resource (webpage) on a website and the browser requests website’s web server for the web page. Another example is when an API is called over HTTPS.

After the TLS handshake, the client and server can start sending encrypted data using the agreed-upon encryption algorithm and the shared session key. This ensures that the communication is secured and protected from unauthorized access and tempering.

3. Steps of a TLS handshake before TLS 1.3

The exact steps of a TLS handshake vary and depend on the kind of key exchange algorithm used and the cipher suites supported by both sides. Before TLS 1.3 RSA key algorithm was used. This algorithm is not used in TLS 1.3 as it is considered less secure.

tls-handshake-process

The steps of TLS handshake using this algorithm are:

  • The “hello” message from client: The client initiates the handshake by sending the ‘hello’ message to the server. The message includes TLS version supported by the client, the supported cipher suites, and a string of random bytes knows as the “client random”.
  • The server responds back with “hello”: In response to the hello message from client, server replies with a hello message. The message contains the server’s SSL certificate, the cipher suite (from the list of cipher suites received from client) and a string of random bytes known as “server random”.
  • Authentication: The client verifies the server’s SSL certificate with the certificate authority that issued it. This confirms the identity of the server.
  • The premaster secret: The client sends random string of bytes, known as “premaster secret”. The “premaster secret” is encrypted with the public key which client received in the certificate from server. This encrypted premaster secret can only be decrypted only with the private key by the server.
  • Server decrypts the premaster secret: Both the server and client have the pre-master secret, the Server Random and the Client Random. They can use that to derive the master secret using the previously agreed cipher and arrive at the same (symmetric) key, which will become the session key once both parties verify their keys match.
  • Session keys are created: Both client and server generate session keys from client random, the server random and the premaster secret.
  • Client is ready: The client sends a “finished” message that is encrypted with a session key.
  • Server is ready: The server also sends a “finished” message encrypted with a session key.
  • The handhake is complete. The communicate between client and server continues using the session keys.

4. Weakness of RSA key exchange

  • The same public-private key pair is used both to authenticate the server and to encrypt the pre-master secret. If an attacker obtains the private key, they will be able to re-generate the session keys and decrypt the entire session.
  • Since the server’s private key doesn’t change, an attacker might record and store encrypted data for years, hoping to decrypt it years down the line if the server’s private key is ever leaked or compromised. So there is no Perfect Forward Secrecy (PFS).
  • It has to make two round trips between the client and server until the session key is established.

5. TLS 1.3 handshake process

TLS 1.3 hanshake process is shorter, faster and more secure. TLA 1.3 handshake does not support RSA and other cipher suites.

  • The client says hello: The client sends a hello message to server. This message contains the protocol version, a list of cipher suites (vastly reduced number in comparison to ealier versions), the client random, the parameters used to calculate the premaster secret. In TLS 1.3 handshake process, client assumes that it knows the servers preferred exchange method.
  • Server generates master secret: The server generates the server random and master secret.
  • Server says hello and “finished” message: The server says hello message to the client. The message includes the server’s certificate, digital certificate, cipher suite (from the list of cipher suites received from client), server random. Since the server has generated the master secret, server also sends a “finished” message.
  • Client sends “finished” message: Client verifies certificate and signature, generates master secret, and sends “finished” message.
  • TLS hanhshake process is complete.

6. What Happens if the SSL/TLS Handshake Fails?

If a TLS/SSL handshake fails, the connection is terminated, and the client receives a 503 Service Unavailable error.

7. Conclusion

In this tutorial, we discussed TLS handshake process. Understanding TLS handshake process is important for setting up resource accessible on https and debugging around this. Otherwise this is just a theoretical topic which is good to know.