Walk me through the TLS 1.3 handshake.

The TLS 1.3 handshake exists to solve one problem: two parties who have never met need to agree on a shared secret over a network an attacker can read, and they need to be sure they are talking to the right party. It does this in one round trip, which is the headline improvement over TLS 1.2.

The flow, step by step

1. ClientHello. The client opens with the TLS version it wants, a random nonce, the cipher suites it supports, the named groups (elliptic curves) it can do ECDHE on, and — crucially — a key share: an ephemeral public key for one or more of those groups. TLS 1.3 is opinionated, so the client guesses the server will accept one of its shares.
2. ServerHello. The server picks a cipher suite and a group, sends back its own ephemeral key share, and now both sides have everything they need to compute the same shared secret via Diffie-Hellman.
3. Key derivation. Both sides run the ECDHE math and feed the result through the HKDF key-derivation function to produce the traffic keys. From this point the rest of the handshake is encrypted.
4. Server authentication. Under that encryption the server sends its certificate and a CertificateVerify — a signature over the handshake transcript that proves it holds the private key for the certificate. The client validates the certificate chain up to a trusted CA.
5. Finished. Both sides exchange a MAC over the whole transcript to confirm nothing was tampered with, and application data flows.

Why it's better than TLS 1.2

• One round trip, not two. Because the client speculatively sends a key share in the first message, the server can reply with everything needed. TLS 1.2 needed an extra round trip.
• Forward secrecy is mandatory. TLS 1.3 removed static RSA key exchange. Every session uses ephemeral keys, so compromising the server's long-term key later does not let an attacker decrypt past traffic they captured.
• A smaller, safer cipher menu. Weak and rarely-correct options (RC4, CBC-mode MACs, renegotiation, compression) were stripped out, shrinking the attack surface.

The trap to watch for

TLS 1.3 adds 0-RTT ("early data"), where a returning client can send application data in its very first message using a pre-shared key. It's fast, but 0-RTT data is replayable by an attacker, so it must only carry idempotent requests — never anything that mutates state. A strong answer mentions this trade-off without prompting.