Certificate Infrastructure Deep Dive — Part 2

Inside the TLS Handshake

In Part 1, we explored the cryptographic primitives that underpin TLS. Now we move from theory to protocol.

This article dissects the TLS handshake at a message and architectural level. We assume familiarity with symmetric crypto, asymmetric keys, and forward secrecy.

1. Layering: TCP → TLS → Application

TLS operates above TCP.

The sequence:

  1. TCP three-way handshake
  2. TLS handshake
  3. Encrypted application data

TLS is not “encryption of TCP” — it is a protocol layered on top of a reliable byte stream.

2. Handshake Flow Diagrams

These diagrams show the typical handshake flow (happy path). Real-world deployments may add optional messages (OCSP stapling, client auth, HelloRetryRequest, etc.).

TLS 1.2 (ECDHE) — Typical Full Handshake

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Server

    C->>S: ClientHello (SNI, ALPN, supported_versions, cipher_suites, groups)
    S->>C: ServerHello (chosen_version, chosen_cipher)
    S->>C: Certificate (chain)
    S->>C: ServerKeyExchange (ECDHE params + signature)
    S->>C: ServerHelloDone
    C->>S: ClientKeyExchange (ECDHE key share)
    Note over C,S: Both derive shared secret -> keys (PRF)
    C->>S: ChangeCipherSpec
    C->>S: Finished (encrypted, transcript hash)
    S->>C: ChangeCipherSpec
    S->>C: Finished (encrypted, transcript hash)
    Note over C,S: Encrypted Application Data begins

Key ideas:

TLS 1.3 — Typical Full Handshake

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Server

    C->>S: ClientHello (supported_versions=1.3, key_share, SNI, ALPN, cipher_suites)
    S->>C: ServerHello (key_share, chosen_cipher)
    Note over C,S: Handshake keys derived (HKDF) -> most messages now encrypted
    S->>C: EncryptedExtensions
    S->>C: Certificate (chain)
    S->>C: CertificateVerify (signature over transcript)
    S->>C: Finished (encrypted, transcript MAC)
    C->>S: Finished (encrypted, transcript MAC)
    Note over C,S: Encrypted Application Data begins

Key ideas:

TLS 1.3 with HelloRetryRequest (When No Compatible Key Share)

This occurs when the client didn’t offer a key share the server accepts (e.g., server requires a different curve/group).

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Server

    C->>S: ClientHello (key_share: group A)
    S->>C: HelloRetryRequest (request group B)
    C->>S: ClientHello (retry, key_share: group B)
    S->>C: ServerHello (key_share: group B)
    S->>C: EncryptedExtensions
    S->>C: Certificate
    S->>C: CertificateVerify
    S->>C: Finished
    C->>S: Finished

Operational note:

Session Resumption (High-Level)

Resumption reduces cost/latency using a PSK established from a prior session.

TLS 1.2 (Session ID / Ticket) — Simplified View

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Server

    C->>S: ClientHello (session_id / ticket)
    S->>C: ServerHello (resumed)
    Note over C,S: Keys derived from resumed parameters
    C->>S: ChangeCipherSpec
    C->>S: Finished
    S->>C: ChangeCipherSpec
    S->>C: Finished

TLS 1.3 (PSK Resumption) — Simplified View

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Server

    C->>S: ClientHello (PSK binder + key_share)
    S->>C: ServerHello
    S->>C: Finished
    C->>S: Finished
    Note over C,S: Application traffic keys active

0-RTT Early Data (TLS 1.3) — Conceptual

0-RTT reduces latency but introduces replay risk. Only safe for idempotent operations.

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Server

    C->>S: ClientHello (PSK binder) + EarlyData (0-RTT)
    S->>C: ServerHello
    S->>C: Finished
    C->>S: Finished
    Note over C,S: 1-RTT protected data continues

3. ClientHello: Where Negotiation Begins

The ClientHello contains:

Critical extensions:

SNI (Server Name Indication)

Allows multiple certificates on a single IP address.

Without SNI:

ALPN (Application Layer Protocol Negotiation)

Allows negotiation of:

Supported Groups

Defines acceptable key exchange groups (e.g., secp256r1, x25519).

4. Cipher Suite Negotiation

In TLS 1.2, cipher suites combine:

Example:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Breakdown:

The server selects one suite from the client’s offered list.

Security note: The server’s choice is constrained by both client support and server configuration.

In TLS 1.3, cipher suites are simplified and mostly represent the AEAD + hash, because key exchange/auth are negotiated via extensions.

5. Certificate Exchange

The server sends:

Client validation involves:

  1. Signature verification
  2. Chain building
  3. Trust anchor verification
  4. Hostname validation (SAN)
  5. Expiry check
  6. Revocation check (often soft-fail)

Failure at any stage aborts the handshake.

6. Key Exchange

TLS 1.2 (ECDHE)

  1. Server sends ephemeral public key parameters
  2. Client generates its ephemeral key pair
  3. Both compute shared secret

Shared secret feeds the PRF to derive:

TLS 1.3

Key exchange happens earlier (ClientHello/ServerHello key shares) and drives the HKDF key schedule.

7. Finished Messages: Transcript Authentication

The Finished message includes a value derived from the full handshake transcript. This ensures a MitM cannot alter negotiation parameters undetected.

TLS 1.3 additionally adds CertificateVerify, a signature over the transcript proving the server owns the private key for its certificate.

8. Session Resumption and 0-RTT

Resumption reduces latency and CPU cost, but changes some security properties.

0-RTT is opt-in and should be limited to replay-safe operations.

9. Observing the Handshake

Tools to inspect TLS handshakes:

Example:

Get-TLSleuthCertificate -Hostname github.com

This exposes:

The handshake is not magic. It is a deterministic negotiation of cryptographic capability, identity, and trust.

Certificate Infrastructure Deep Dive