TLS¶

What TLS adds: confidentiality (encryption), integrity (MAC), authentication (server certificate).

TLS 1.2 (2 RTTs): ClientHello → ServerHello + cert → key exchange → Finished. Client derives session key from pre-master secret + randoms. With RSA key exchange: no forward secrecy — compromised server private key decrypts all past sessions.

Forward secrecy (ECDHE): ephemeral DH key pair per session. Session key derived from ephemeral private key, discarded after session. Past sessions cannot be decrypted even if the server's long-term private key is later compromised.

TLS 1.3 (1 RTT): mandatory ECDHE, 1-RTT handshake (client sends DH key share immediately), application data starts after one round trip. 0-RTT resumption for returning clients (data in first packet — not replay-safe, use only for idempotent requests).

Worked example — why forward secrecy matters even if nothing looks wrong today: an attacker passively records a company's encrypted traffic for a year, unable to read any of it. Two years later, that company suffers a breach and its TLS private key leaks. With RSA key exchange (no forward secrecy), the session key for every recorded session was derived directly from that private key — the attacker can now decrypt all two years of recorded traffic retroactively. With ECDHE, each session used a fresh, ephemeral Diffie-Hellman key pair that was discarded the moment the session ended; the long-term private key was only ever used to sign the handshake for authentication, not to derive the session key. The leaked key lets the attacker impersonate the server going forward, but every past recorded session stays unreadable, because the ephemeral keys that could decrypt them no longer exist anywhere. This is the concrete reason TLS 1.3 made ECDHE mandatory instead of optional.