TLS 1.3 Handshake Explained: A Guide

TLS Handshake

Basic Definition

The TLS (Transport Layer Security) Handshake is a cryptographic process that establishes a secure, encrypted connection between a client (e.g., a web browser) and a server (e.g., a website server) before any application data is transmitted. It ensures mutual authentication (verifying each party’s identity), negotiates encryption algorithms and keys, and sets up parameters for the secure session—all to prevent eavesdropping, tampering, or forgery of data in transit. TLS (the successor to SSL) is the foundation of secure web communication (HTTPS), email, and other network services.

Core Goals of the TLS Handshake

Authentication: Verify the server’s identity (and optionally the client’s) using digital certificates.
Key Exchange: Safely share a symmetric session key (used to encrypt/decrypt data) over an insecure network.
Cipher Suite Negotiation: Agree on encryption algorithms (e.g., AES for symmetric encryption, RSA for key exchange, SHA-256 for hashing) that both parties support.
Session Initialization: Set up parameters (e.g., session ID, sequence numbers) for the secure session.

Step-by-Step TLS 1.3 Handshake (Modern Version)

TLS 1.3 (released in 2018) simplified the handshake from TLS 1.2 (which required 2–3 round trips) to just 1 round trip (1-RTT) for faster connection setup. Below is the standard full handshake (client and server authentication):

1. Client Hello

The client sends a ClientHello message to the server, containing:
- TLS Version: The highest TLS version the client supports (e.g., TLS 1.3).
- Cipher Suites: A list of encryption algorithms the client can use (e.g., TLS_AES_256_GCM_SHA384).
- Random Value: A 32-byte random number (client_random) to seed key generation.
- Session ID: (Optional) A reference to a previous session for session resumption (to skip the full handshake).
- Extensions: Additional features (e.g., supported_groups for key exchange algorithms like ECDHE, signature_algorithms for certificate verification).

2. Server Hello + Server Parameters

The server responds with a ServerHello message, selecting:
- TLS Version: The highest mutually supported version (e.g., TLS 1.3).
- Cipher Suite: A cipher suite from the client’s list (e.g., TLS_AES_256_GCM_SHA384).
- Random Value: A 32-byte server random number (server_random).
- Session ID: A unique ID for the new session (or the client’s ID for resumption).
The server then sends:
- Server Certificate: A digital certificate (signed by a trusted CA) containing the server’s public key and identity (domain name).
- Server Key Exchange: (For TLS 1.3, integrated into ServerHello) The server’s ephemeral public key (for ECDHE key exchange) to compute the shared secret.
- Certificate Verify: A digital signature (using the server’s private key) of the handshake messages (to prove the server owns the certificate’s private key).
- Server Hello Done: Signals the end of server hello messages.

3. Client Authentication (Optional)

If the server requires client authentication (e.g., for banking or enterprise apps):

The client sends its own certificate (signed by a CA) to the server.
The client signs the handshake messages with its private key (Client Certificate Verify) to prove identity.

4. Key Exchange & Premaster Secret

Both client and server use the client_random, server_random, and ephemeral keys (from ECDHE) to compute a premaster secret (a shared secret unknown to third parties).
The premaster secret is combined with the random values and a hash function to generate the session keys:
- Encryption Key: For symmetric encryption of data (AES).
- MAC Key: For message authentication (to detect tampering).
- IV (Initialization Vector): For block cipher modes (e.g., GCM).

5. Client Finished

The client sends a Finished message, which is a hash of all previous handshake messages encrypted with the session key.
This proves the client has computed the correct session keys and the handshake was not tampered with.

6. Server Finished

The server responds with its own Finished message (hash of handshake messages encrypted with the session key).
This confirms the server has the correct session keys and the handshake is complete.

7. Secure Data Transfer

The client and server now use the session key to encrypt/decrypt all application data (e.g., HTML, images, form data) for the duration of the session.

TLS 1.2 Handshake (Legacy Version)

TLS 1.2 (still widely used) has a slightly longer handshake (2-RTT) due to separate key exchange steps:

Client Hello (same as TLS 1.3).
Server Hello + Certificate + Server Key Exchange + Server Hello Done.
Client Key Exchange: Client sends its ephemeral public key to compute the premaster secret.
Client Change Cipher Spec: Signals the client will use the session keys for future messages.
Client Finished.
Server Change Cipher Spec.
Server Finished.

Key Components of the TLS Handshake

1. Cipher Suites

A cipher suite is a combination of algorithms for:

Key Exchange: How the premaster secret is shared (e.g., ECDHE for forward secrecy, RSA for static key exchange).
Authentication: How identities are verified (e.g., RSA, ECDSA).
Symmetric Encryption: How data is encrypted (e.g., AES-GCM, ChaCha20).
Hash Function: For message integrity (e.g., SHA-256, SHA-384).

Example: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Key exchange: ECDHE
Authentication: RSA
Encryption: AES-256-GCM
Hash: SHA-384

2. Digital Certificates

Issued by a Certificate Authority (CA) (e.g., Let’s Encrypt, DigiCert), a server certificate contains:

The server’s public key.
The server’s domain name (or wildcard for subdomains).
The CA’s digital signature (verifying the certificate’s authenticity).
Validity period (start/end dates).

3. Forward Secrecy

Enabled by ephemeral key exchange algorithms (e.g., ECDHE, DHE), forward secrecy ensures that even if the server’s private key is compromised, past sessions remain secure. Each session uses a unique ephemeral key pair, so old session keys cannot be derived from the private key.

4. Session Resumption

To avoid redoing the full handshake for subsequent connections, TLS supports:

Session IDs: The server stores session parameters (e.g., session key) and assigns a session ID to the client. The client reuses the ID to resume the session.
Session Tickets: The server encrypts session parameters into a ticket (sent to the client), which the client returns to resume the session (no server-side storage needed).

TLS Handshake Failures & Common Issues

Certificate Mismatch: The server’s certificate does not match the domain name (e.g., a certificate for example.com used on sub.example.com).
Expired/Revoked Certificate: The server’s certificate is expired or has been revoked by the CA (e.g., due to a private key breach).
Unsupported Cipher Suite: Client and server share no common cipher suites (e.g., client only supports TLS 1.3, server only supports TLS 1.2).
Man-in-the-Middle (MitM) Attack: An attacker intercepts the handshake and presents a fake certificate (blocked by browsers if the CA is untrusted).
Slow Handshake: Legacy TLS versions (1.2 or earlier) add latency due to extra round trips (mitigated by TLS 1.3).