How HTTPS works
DNS gave the browser an address; now it has to talk to that server without anyone reading or changing the conversation. Follow one TLS 1.3 connection to www.example.com: the TCP handshake, the key exchange, the certificate check, then the encrypted request and response.
5 quick questions
Pick an answer to see why. Your score saves with your progress.
01How does the shared encryption key get from the browser to the server?
That is ECDHE (here X25519). Only public keys cross the wire; the shared secret is computed separately on each side.
02What does the CertificateVerify message prove?
A certificate is public; anyone can send a copy. Only the real server can sign the handshake transcript with the matching private key.
03Which of these can an on-path eavesdropper still see on an HTTPS connection?
IPs, ports, the plaintext hellos (including SNI unless Encrypted Client Hello hides it) and record sizes and timing are visible. The HTTP content is encrypted.
04Why does the browser check that the leaf certificate's name matches www.example.com?
A trusted CA signs certificates for many sites. Without the name check, any site's valid certificate could impersonate this one.
05What is forward secrecy?
The X25519 key pairs are fresh for each connection and discarded afterwards; the certificate key only signs, it never protects the session key.
Glossary
- TLS
- Transport Layer Security: the protocol that encrypts and authenticates the connection. HTTPS is HTTP sent inside TLS.
- Handshake
- The opening messages in which both sides agree on a version, cipher suite and keys, and the server proves its identity.
- ECDHE
- Ephemeral elliptic-curve Diffie–Hellman: each side mixes its private key with the other's public key to reach the same secret.
- Cipher suite
- The encryption and hash pair used after the handshake, here TLS_AES_128_GCM_SHA256.
- Certificate chain
- The server's certificate plus the intermediate that signed it, leading up to a root CA the browser already trusts.
- SNI
- Server Name Indication: the host name the browser puts in the ClientHello so one IP can serve many sites.
- Finished
- A MAC over the whole handshake that proves neither side's view of it was tampered with.
- Forward secrecy
- Recorded traffic stays safe even if a long-term key is stolen later, because session keys came from throwaway key pairs.
Notes and sources
- Times are illustrative: a 40 ms round trip and about 1 ms of local crypto work.
- 192.0.2.7 and 203.0.113.10 are RFC 5737 documentation addresses; the CA names are illustrative.
- On a later visit the browser can resume with a pre-shared key from a NewSessionTicket and even send 0-RTT early data with its first flight; early data can be replayed, so servers accept it only for safe requests.
- Encrypted Client Hello (ECH) encrypts the inner ClientHello, SNI included, to a key the server publishes in DNS.
- Messages sent in the same flight are shown one after another; their times overlap on the clock.
Quiz Unlocks after the last step.