The 1-RTT handshake: key shares and ECDHE

The browser opens a TCP connection and immediately sends a ClientHello. That single message carries the cipher list AND the client’s half of the encryption key — the server can compute the shared secret on the spot and reply with encrypted data in one pass. This is how TLS 1.3 cuts two round-trips to one.

The 1-RTT handshake step by step

Step 1 — ClientHello. The client sends: the TLS version list (via the supported_versions extension), supported cipher suites, supported named groups (curves), supported signature algorithms, and a key_share extension containing at least one ECDHE public key — typically x25519.

Step 2 — ServerHello. The server picks a cipher suite (e.g. TLS_AES_128_GCM_SHA256), picks a named group from the client’s key_share, generates its own ephemeral keypair, and replies with its public key. Both sides now have each other’s ephemeral public keys and can run ECDHE to derive the shared secret.

Step 3 — Encrypted handshake. The server immediately derives the handshake traffic key from the shared secret and sends EncryptedExtensions, Certificate, CertificateVerify, and server Finished — all encrypted — back to back in the same network pass.

Step 4 — Client completes. The client derives the same handshake traffic key, decrypts the server’s messages, validates the certificate chain, validates the CertificateVerify signature over the transcript, verifies the server Finished HMAC, sends client Finished, and starts sending application data.

Total round-trips: one. ClientHello leaves the client, ServerHello + encrypted handshake arrive, client Finished + first app data leave — all in a single network exchange.

ECDHE: the key exchange behind key shares

Both sides agree on a curve (usually x25519 for performance, or P-256 for FIPS). Each generates a private scalar (a random 256-bit integer) and computes a public point: public = private · G, where G is the curve’s base generator. Bea sends her public point in the key_share; Sven sends his back. Each side computes the shared secret by multiplying the other’s public point by their own private scalar:

• Bea: shared = bea_private · sven_public
• Sven: shared = sven_private · bea_public

Both arrive at the same point on the curve. An eavesdropper who saw only the public points cannot recover it without solving the elliptic-curve discrete-log problem — intractable for properly sized curves on classical hardware.

Perfect Forward Secrecy (PFS)

Both the client and server use ephemeral key pairs generated fresh for this connection and discarded after it. If an attacker later steals Sven’s long-term private key from his disk, the attacker cannot decrypt past sessions — those sessions used ephemeral keys that are already gone. This is Perfect Forward Secrecy.

TLS 1.2 allowed RSA key transport: the client encrypted the session secret with the server’s long-term public key. Stealing the private key meant decrypting every recorded past session. TLS 1.3 mandates ephemeral key exchange, making PFS the default with no configuration needed.

Certificate chain validation

When the client receives Certificate, it sees a chain: the leaf certificate for the hostname, then one or more intermediate certificates. It walks the chain bottom-up:

1. Verify the leaf was signed by the intermediate’s public key.
2. Verify the intermediate was signed by a root.
3. Confirm the root is in the local trust store (the CA bundle shipped with OS/browser).
4. Check the leaf’s Subject Alternative Names (SANs) include the connection hostname.
5. Check validity period (notBefore <= now <= notAfter).
6. Check revocation (CRLite, stapled OCSP, or short-lived cert policy).

If any step fails, the connection terminates with a fatal alert (e.g. unknown_ca).

The transcript hash and Finished

Every byte sent during the handshake is fed into a running SHA-256 digest called the transcript hash. The Finished message is HMAC(finished_key, transcript_hash). If a single bit on the wire was flipped or replaced — by a network bug or a man-in-the-middle — the HMAC will not match and the connection aborts. This is how TLS 1.3 detects downgrade attacks: the transcript records the version the client originally proposed, so a middlebox that tries to force TLS 1.2 breaks the Finished check.