Explain how a TLS handshake turns an untrusted network into an authenticated confidential channel: which job the public-key operations do, which job the symmetric keys do, and what forward secrecy means for a connection recorded today and attacked years later.

## Two jobs, deliberately separate It is tempting to describe a handshake as a sequence of messages. The useful description is functional: the handshake must accomplish two independent things, and confusing them is the source of most misconceptions. **Job one: agree on a secret.** Both parties generate a fresh ephemeral key pair for this connection, send the public halves, and each combines its own private value with the peer's public value to compute the same shared secret. The secret itself never crosses the network, and an observer who saw both public values cannot compute it. Both sides also send random nonces. **Job two: know who you agreed with.** Key agreement is anonymous. Run alone, it gives you a shared secret with whoever answered, which an on-path attacker is happy to be - it agrees one secret with you and another with the real server, and relays. So the server must prove it is the party the certificate names: it signs the handshake transcript (everything exchanged so far) with the private key corresponding to the public key in its certificate. Only the legitimate key holder can produce that signature, and because the signature covers the transcript, it is bound to *this* handshake and *these* key shares, not reusable from a recorded one. ## From shared secret to record keys The raw agreed secret is not used directly. It is fed through a key-derivation function together with the transcript and the nonces, producing separate keys for each direction and each purpose - so the client-to-server keys differ from the server-to-client keys, and handshake protection differs from application-data protection. Key separation by purpose is deliberate: it prevents a weakness or an oracle in one direction or phase from touching another, and it prevents records from being reflected back to their sender. After that, all application data is protected symmetrically. The expensive public-key work happens once per connection; per-byte cost is symmetric and cheap. That is why connection reuse and resumption matter for capacity. ## The misconception worth killing Many candidates describe the handshake as: the client generates a random session key, encrypts it with the server's public key from the certificate, and sends it. That mechanism genuinely existed - RSA key transport - and it has a fatal property. The session key is recoverable by anyone who ever obtains the server's long-term private key. An adversary records ciphertext today, obtains the private key months later by breach, compulsion or misconfiguration, and decrypts every recorded session retroactively. One key compromise equals retroactive disclosure of all past traffic. TLS 1.3 removed static-RSA key exchange entirely for this reason; TLS 1.2 deployments were expected to prefer ephemeral exchange for the same reason. ## Forward secrecy, precisely Forward secrecy is the property that compromise of long-term keys does not compromise past session keys. It is achieved by making the key-establishment values ephemeral: they are generated for one connection, used to derive the session secret, and then destroyed. There is nothing left to seize afterwards - the long-term private key only ever *signed*, it never decrypted anything, so it cannot recover past traffic. Two notes usually missed. First, forward secrecy is a property of the key *exchange*, not of the cipher: 'we use AES-256' says nothing about it. Second, it is only as good as the discarding: session tickets and resumption caches can hold material that reconstructs session keys, so a long-lived, rarely-rotated ticket-encryption key silently reintroduces exactly the retroactive-decryption exposure that ephemeral exchange removed. Ticket keys must be short-lived and rotated. ## Freshness and transcript binding Both sides contribute nonces, so no two handshakes derive the same keys and a recorded handshake cannot be replayed to re-establish a known session. At the end of the handshake each side sends a value computed over the entire transcript under the derived keys. This is the negotiation's own integrity check: if an on-path attacker edited the offered versions, the cipher suite list, the extensions or the key shares, the two sides' transcripts differ, the check fails, and the handshake aborts. Downgrade by editing the negotiation is therefore detected rather than silently accepted - though transcript binding cannot save you if both peers genuinely support and agree on a weak option, which is a separate matter of what you refuse to offer. ## Resumption and early data Re-doing the full asymmetric work on every connection is expensive, so protocols support resumption from a previously established secret. The trade is explicit: resumption without a fresh key-agreement step inherits its secrecy from the stored material rather than from new ephemeral values. Where forward secrecy matters, resumption should include a fresh exchange. TLS 1.3 also allows data to be sent in the very first flight, before the handshake completes. This early data is replayable by design - an attacker can capture and resend it, and the server cannot distinguish a replay at that point - so it must only carry operations that are safe to repeat. Treating it as ordinary traffic is a real correctness and security bug, not a theoretical one. ## The one-sentence summary Ephemeral agreement supplies a fresh secret nobody transmitted; a signature over the transcript ties that secret to a name; derivation turns it into per-direction symmetric keys; discarding the ephemeral values is what makes recorded traffic safe from a future key compromise.