Transport Layer Security Handshake

cryptography

Definition

Transport Layer Security Handshake

The TLS handshake is the protocol by which a TLS connection is established. In TLS 1.2 it consists of four message flights between client and server.

Steps

Step 1 — Security Parameter Negotiation

The client sends a ClientHello containing:

• the highest TLS version it supports
• a list of supported cipher suites and compression methods
• a random byte sequence for computing the master secret

The server replies with a ServerHello containing:

• the selected TLS version, cipher suite, and compression method
• a random byte sequence for computing the master secret

If the server cannot select a mutually acceptable TLS version, cipher suite, or compression method, the connection is terminated.

Step 2 — Server Authentication and Key Exchange

The server sends:

• Certificate
  • sent if server authentication is enabled; contains the server certificate chain
  • the client validates this chain
  • the certificate must be appropriate for the authentication algorithm in the selected cipher suite (for example, DHE_RSA requires an RSA public key and the digitalSignature key usage)
• ServerKeyExchange
  • sent only when additional information is needed to establish a premaster secret
  • for ephemeral Diffie-Hellman: prime modulus $P$, generator $g$ (chosen by the server), and the server’s public value $g^{\mathrm{prv}}\mathrm{mod}P$ (where the private value is randomly generated)
  • if server authentication is enabled, these values and the random sequences from step 1 are signed
• CertificateRequest
  • optional; requests client authentication
• ServerHelloDone
  • marks the end of step 2

Step 3 — Client Authentication and Key Exchange

The client sends:

• Certificate
  • the client certificate, if requested
• ClientKeyExchange
  • the client’s key exchange material; for Diffie-Hellman, the client’s public value $g^{\mathrm{prv}}$ (where the private value is chosen by the client) using the server’s $g$ and $P$
• CertificateVerify
  • a signature over all previous handshake messages, sent only if a client certificate was provided
• ChangeCipherSpec
  • signals that the negotiated algorithms and parameters will be used from now on
• Finished
  • the first message encrypted with the negotiated symmetric key
  • contains verify data computed over all prior handshake messages

Step 4 — Handshake Completion

The server sends:

• ChangeCipherSpec
  • signals that the negotiated algorithms and parameters will be used from now on
• Finished
  • the first encrypted message under the negotiated symmetric key
  • contains verify data computed over all prior handshake messages

Validation

Validation of the Server’s Certificate

Validation of the Server Certificate Chain

The client verifies each certificate in the chain as follows:

• The signature is verifiable with the public key in the next certificate (or, for the root certificate, with its own public key).
• The certificate is within its validity period.
• The certificate has not been revoked (optional).
• Each certificate except the first is valid for signing certificates.

For the end-entity certificate, the client checks that one of the domains listed — a certificate may contain multiple domains — matches the target domain.

Finished Verification

Verify Data

The Finished messages carry $\text{verify\_data}$ computed via the PRF as

$$\text{PRF}(\text{master\_secret},\text{label},\mathrm{Hash}(\text{handshake\_messages}))$$

where the label is "client finished" from the client and "server finished" from the server.

Both peers hash the exact same transcript, but each uses a distinct label. The receiver recomputes the expected value and checks for equality.

The master secret is already derived before Finished (from the premaster secret and the two random sequences). Hence Finished does not establish the master secret — it confirms that both sides derived the same one and that neither transcript was altered.

Key Derivation

Pre-master Secret

The premaster secret depends on the key exchange mechanism. For Diffie-Hellman, both parties compute it from their own private value and the peer’s public value.

Master Secret and Session Keys

The master secret is derived from the premaster secret and the two random sequences from step 1. All subsequent keys — encryption keys and HMAC keys — are derived from the master secret.