TLS Handshake Explained

TLS 1.3 completes a fresh handshake in one round trip, down from TLS 1.2's two. The client sends a ClientHello listing supported cipher suites and, critically, a key_share extension containing ephemeral Diffie-Hellman public values for the groups it thinks the server is likely to pick — sent opportunistically, before the server has said anything, which is what collapses the handshake to one round trip instead of negotiating the group first and exchanging keys second.

The server responds with ServerHello (its chosen cipher suite and its own key share, letting both sides now independently derive the same shared secret), and — already encrypted using that just-derived secret — sends EncryptedExtensions, its Certificate, a CertificateVerify (proving it holds the certificate's private key), and a Finished message. The client verifies the certificate chain, sends its own Finished, and application data can begin flowing immediately after. Compare this to TLS 1.2, which needed a full round trip just to agree on a cipher suite before any key material was exchanged at all.

Older TLS versions allowed a static RSA key exchange: the client encrypted a secret directly with the server's long-term RSA public key. This meant that if the server's private key was ever compromised — stolen, subpoenaed, or leaked — years of previously recorded encrypted traffic could be decrypted retroactively, because that same long-term key had been used to protect every one of those past sessions.

TLS 1.3 removed static RSA key exchange entirely, requiring (EC)DHE — ephemeral Diffie-Hellman — for every handshake. Each connection generates a fresh, temporary key pair used only for that one session and discarded immediately after; the server's long-term certificate key is used only to sign the exchange (proving identity), never to directly encrypt the shared secret. This is forward secrecy: compromising the server's long-term private key today reveals nothing about any past session, because past sessions never depended on that key for their actual encryption — each one used its own now-discarded ephemeral key.

Verifying a certificate means walking its chain up to a trusted root CA, checking the certificate's validity dates, and confirming the hostname being connected to matches one of the certificate's Subject Alternative Names — a mismatch here is what produces the browser's "certificate not valid for this domain" warning. The remaining question is revocation: has the certificate been invalidated before its expiry date, for example because its private key leaked?

The traditional approach — the client separately querying the CA's OCSP (Online Certificate Status Protocol) responder for every connection — is slow (an extra round trip to a third party) and leaks privacy (the CA learns every site you visit, from every one of your revocation checks). OCSP stapling fixes both: the server itself periodically fetches a signed, time-stamped "not revoked" response from the CA and includes ("staples") it directly in the TLS handshake, so the client verifies revocation status from a signature it already received, with no separate call to any third party at all.

Trigger. A client that previously connected to a server resumes the session using 0-RTT: it sends application data — in this case, a POST /payments/retry request — in its very first flight, using a pre-shared key derived from the earlier session, without waiting for any round trip at all. Symptom. An attacker who captured that first flight off the network replays the identical encrypted 0-RTT data later; the server, having no way within TLS itself to distinguish a legitimate resend from a malicious replay, processes the payment retry a second time.

Root mechanism. 0-RTT data arrives before the handshake's anti-replay protections (which depend on a completed round trip) are in effect — this is a documented property of the 0-RTT design, not an implementation bug, and RFC 8446 explicitly warns that 0-RTT data is replayable. Recovery: the payment retry endpoint's own idempotency key (the same pattern covered in Exactly-Once Delivery) catches the duplicate at the application layer, where TLS cannot. Verification: confirm the payment provider shows exactly one successful charge despite two identical requests reaching the server. Prevention: only ever enable 0-RTT for genuinely idempotent requests (a cacheable GET, a read with no side effect) — never for a state-changing action — or disable 0-RTT entirely for endpoints that can't guarantee idempotency at the application layer.