Part III · 2 — TLS: everything together

draft

TLS is the protocol that protects the web — and the best example of how the primitives of Parts I–II fit together. In a single handshake there are key exchange, symmetric cipher, MAC, signature, and PKI, each in its role.

2.1 What TLS delivers

TLS (Transport Layer Security, successor to SSL) gives a connection three guarantees, over TCP:

  • Confidentiality — no one on the path reads the data.
  • Integrity + authenticity — no one alters the data without being detected.
  • Server authentication (and optionally client authentication) — you really are talking

    to koder.dev, via the certificate chain from the previous section.

The version to use is TLS 1.3 (RFC 8446, 2018): faster, simpler, and one that removed all the fragile legacy algorithms of previous versions.

2.2 The 1.3 handshake, piece by piece

The TLS 1.3 handshake completes in one round trip (1-RTT). See where each primitive enters:

The TLS 1.3 handshake: ClientHello, ServerHello, certificate, Finished

  1. ClientHello — the client sends supported versions, the AEAD ciphers it accepts,

    and its public ECDHE share (an ephemeral key; Part II).

  2. ServerHello — the server picks the cipher, sends its ECDHE share —

    and from here on both already derive the shared secret (ECDHE) and, via HKDF (Part II), the symmetric session keys.

  3. Certificate + CertificateVerify — the server sends its *ertificate

    chain (PKI) and signs*the handshake with its private key (Ed25519/RSA-PSS). This is what proves "I really am koder.dev" — it is not enough to have done the ECDHE, you must sign.

  4. Finished — a MAC over the entire transcript, on both sides, ensures

    that no one tampered with the handshake messages (anti-downgrade).

  5. Application data — from here on, everything encrypted with AEAD

    (AES-GCM / ChaCha20-Poly1305) using the derived keys.

Notice: the ECDHE gives forward secrecy and the secrecy; the signature over the certificate gives the identity. Both are necessary — confidentiality without authentication would be a secure tunnel to an impostor.

2.3 Why each piece exists

Handshake piece Primitive Without it…
ClientHello/ServerHello key share ECDHE (ephemeral asymmetric) no session secret; no forward secrecy.
Key derivation HKDF no symmetric keys from the secret.
Certificate + Verify signature + PKI a MITM impersonates the server.
Finished MAC over the transcript downgrade to a weak cipher.
Application data AEAD no confidentiality/integrity of the data.

It is the thesis of Part I in action: work at the protocol layer (TLS), which orchestrates the primitives — never build this by hand.

2.4 TLS's cousins

The same fit reappears in other secure-transport protocols:

  • SSH — remote access; key exchange + host keys (trust on

    first use, TOFU) + session cipher.

  • WireGuard — a modern, minimalist VPN, based on the Noise framework: only

    curves (Curve25519), ChaCha20-Poly1305, and BLAKE2 — without the zoo of IPsec options. The recommended replacement for IPsec/IKE when possible.

  • QUIC — the transport of the modern web (HTTP/3) with the TLS 1.3 handshake

    built in.

Dense reference: the complete handshake, the historical failures (BEAST, Heartbleed, downgrade), SSH, IPsec, and WireGuard are in 07-protocols. Next: Messaging and Signal — where trust is not in a server, but end-to-end between people.