Understanding the TLS Handshake: Step-by-Step Guide to Secure Communication

TLS Handshake Overview

The TLS (Transport Layer Security) handshake establishes an encrypted session between a client and a server. It authenticates the parties (when certificates are used) and derives shared secret keys that protect all subsequent application data.

ClientHello

The client initiates the connection with a ClientHello message that includes:

Supported protocol version(s) (e.g., TLS 1.2, TLS 1.3).

A list of offered cipher suites, each describing key‑exchange, authentication, encryption, and MAC algorithms.

Supported compression methods (usually null).

A 32‑byte random value called Client Random .

Optional extensions such as Server Name Indication (SNI), supported groups, and signature algorithms.

ServerHello

The server replies with a ServerHello that selects the highest‑priority cipher suite and protocol version mutually supported.

It provides its own 32‑byte Server Random and may include extensions (e.g., key‑share for TLS 1.3).

Server Certificate and Key Exchange

The server sends its X.509 certificate chain in a Certificate message; the leaf certificate contains the server’s public key.

If the chosen cipher suite requires additional parameters (e.g., Diffie‑Hellman, ECDHE), the server follows with a ServerKeyExchange message containing the necessary key‑exchange data and a digital signature.

ServerHelloDone

The server signals the end of its handshake messages with a ServerHelloDone message.

Client Key Exchange

Depending on the key‑exchange method, the client sends a ClientKeyExchange message. For RSA‑based suites the client encrypts a 48‑byte pre‑master secret with the server’s public key; for (EC)DHE suites the client sends its key‑share value.

ChangeCipherSpec and Finished (Client)

The client sends a ChangeCipherSpec record to inform the server that subsequent records will be protected with the newly derived keys.

Immediately after, it sends a Finished message, which contains a MAC over the entire handshake transcript. This proves that the client possesses the correct key material.

ChangeCipherSpec and Finished (Server)

The server performs the same steps: a ChangeCipherSpec followed by its own Finished message, confirming that both sides have derived identical session keys.

Application Data Transfer

From this point onward, all application data is encrypted and authenticated with the negotiated symmetric cipher (e.g., AES‑GCM, ChaCha20‑Poly1305) and the keys derived from the pre‑master secret, Client Random , and Server Random .

In TLS 1.2 the master secret is derived with the PRF function; in TLS 1.3 the handshake uses HKDF‑based key derivation and many of the above messages are combined (e.g., the server’s certificate and Finished are sent after an encrypted EncryptedExtensions message). Nevertheless, the fundamental goal remains the same: mutual authentication (when certificates are presented) and agreement on a shared secret that protects subsequent communication.