The TLS 1.3 handshake in outline

What it is

RFC 8446 defines the handshake. The client sends a ClientHello with the supported_versions, signature_algorithms and key_share extensions; the key share is an ephemeral (EC)DHE public value for one or more groups. The server picks a group and replies with a ServerHello carrying its own key_share. Both sides now derive handshake keys, and every following message is encrypted: EncryptedExtensions, the server's Certificate and CertificateVerify (a signature over the transcript), and Finished (an HMAC over the transcript). The client answers with its own Finished and can then send application data. One round trip, hence "1-RTT". If the client guessed a group the server does not support, the server sends HelloRetryRequest and the client retries with a different key share, costing one more round trip.

After the handshake the server may send NewSessionTicket messages; a later connection presents the ticket as a pre_shared_key and can skip certificate exchange. With such a PSK the client may also send "early data" (0-RTT) in its first flight. The RFC states plainly that 0-RTT data is not forward secret and that there are no guarantees of non-replay between connections.

Why it matters

RFC 8446 lists what was removed relative to TLS 1.2: static RSA and Diffie-Hellman cipher suites (RSA key transport), compression, DSA, custom DHE groups and the legacy symmetric ciphers; renegotiation is forbidden outright. Every public-key key exchange now provides forward secrecy and every remaining suite is AEAD (TLS_AES_128_GCM_SHA256 is mandatory to implement). The certificate is no longer visible on the wire, which changes what passive middleboxes and logging can see.

How to apply

• Prefer TLS 1.3 wherever both ends support it; the version is negotiated through supported_versions, not the legacy version field, so old middleboxes that inspect that field still see "TLS 1.2".
• Offer the key-share group the expected peers prefer first to avoid HelloRetryRequest round trips; the RFC requires secp256r1 and recommends X25519 for clients.
• Leave 0-RTT off unless the application layer only sends idempotent requests early; the RFC's anti-replay section describes single-use tickets and freshness checks that a server would need.
• Prefer resumption with a fresh key share (psk_dhe_ke): the RFC states that a PSK used alone loses forward secrecy for the application data, so a leaked ticket key would expose those sessions. Rotate ticket keys regardless.

Pitfalls

"Middlebox compatibility mode" makes TLS 1.3 look like a 1.2 session resumption on the wire; packet captures therefore need the session secrets, not just the certificate, to be decrypted. Client certificates still work but are requested inside the encrypted part of the handshake, so proxies that terminate TLS must handle them themselves.