A TLS (Transport Layer Security) session consists of several phases to establish a secure connection between a client and a server. These phases ensure that the data transmitted is encrypted and that both parties are authenticated (in the case of mTLS, mutual authentication is included).
During the handshake:
- Client and server acknowledge each other
- Verify each other's identity (in TLS only server's identity is verified, in mTLS both)
- Set up the parameters for a secure connection (set of cryptographic algorithms to be used during the session --> see cipher suite)
In this post, we'll see the 10 steps that a client and a server follow during a handshake of a TLS session. We normally break down the handshake process into two phases: Authentication (steps 1 to 5) and key exchange (steps 6 to 10). However, as we'll see during the Authentication phase both parties acknowledge each other and negotiate the parameters of the connection.
Authentication Phase
Step 1 - Client Hello
The client sends a hello message to the server. In this message it includes:- The highest version of SSL/TLS that the client supports
- Lists of all cipher suites supported by the client
- Data compression models
- A session ID equals to 0
- A random data - this is just to add entropy to the submitted key generation (the more entropy, the more unpredictable the symmetric key will be)
Step 2 - Server Hello
On receiving the client hello the server responds with:
- The SSL/TLS version
- The selected cipher suite for communication
- The data compression method that the server supports
- An ID is assigned for the session, this is when the session ID gets its actual data
- Random data for entropy
- The server certificate, which contains the server’s public key and the signature from the Certificate Authority (CA) who signed the certificate
- It contains an optional field to mention if it requires a certificate back from the client (for mutual TLS)
- At the end, it will include a server hello done command to indicate the end of the information
Step 3 - Client verifies Server's identity
- The client now verifies the server’s certificate. It checks if the CA signing the certificate is in the list of trusted CAs. If so, it loads the public key of the CA and verifies the signature of the certificate.
- If the signature is not valid the client produces a warning message or just closes the connection.
Step 4 (Only in mTLS) - Client sends its certificate
- This step is done only if the server has requested a client certificate
Step 5 (Only in mTLS) - Server verifies Client's identity
- If mTLS is required, the server will verify it
Key Exchange Phase
These are the steps in which the client and the server come to a consensus on the symmetric key they will use to encrypt the data during the SSL/TLS session.
Step 6 - Public Key Exchange or Key generation
Key exchange can be done in different ways. The most common methods are RSA and Deffie-Hellman.- RSA is a public key encryption algorithm and can be used for key exchange. It’s the most used method for public key exchange
- Here, the client uses the server’s public key, which was sent in step 2-server hello to encrypt a Pre-Master Secret (PMS). The PMS is decided by the client
- The final master secret that will be used to encrypt the data is calculated using this PMS and the random numbers sent by both parties in steps 1 and 2
- The final master secret will be calculated independently at both, server and client, with the same info, so that both get to calculate the same common secret and it is never transmitted over the wire
- And that info is made up of three components: PMS + random numbers generated from the client + random numbers generated from the server
- One disadvantage is that this mechanism does not offer Perfect Forward Secrecy (PFS)
- Diffie-Hellman (DH) is the most efficient and recommended method
- The main advantage of DH is that there’s no transfer of PMS
- Both the client and server calculate the master secret key independently
- It does not use the public key of the certificate
- The version of this algorithm called Diffie-Hellman Ephimeral (DHE) provides Perfect Forward Secrecy. In DHE, the secret keys are used by the client and server to calculate the master secret key changes for every session. So breaking into an SSL/TLS session impacts only on that session. No other sessions recorded in the past are compromised
Step 7 - Change cipher spec
- This finalizes the cipher specification, this is the final chance to adjust the specification
- This is also the first encrypted communication using the master secret key
Step 8 - The client closes the handshake
This means that after this message the client will send only encrypted messages.
Steps 9 and 10 - The Server closes the handshake
Similar steps from the server. The server finalizes the cypher spec and closes the handshake. Same meaning for the server. After this, all messages from the server will be encrypted.