Web Security's HTTP/HTTPS lesson and this domain's own TLS lesson each described pieces of this separately. This closing lesson walks through one real HTTPS request, start to finish, naming exactly which primitive from this entire domain handles each step — the synthesis that turns eleven separate lessons into one coherent picture.
3 min read
https://example.comEvery mechanism this domain has covered individually shows up, in order, within the first fraction of a second of a single HTTPS connection.
The moment a connection starts, the server presents its TLS certificate.
This certificate is a digitally signed statement (lesson 4's signing
mechanism) that a specific public key belongs to example.com, signed by
a Certificate Authority.
The browser checks the CA's signature on the certificate, and follows the
chain of trust (lesson 7) up through any intermediate CAs to a root
CA it already has pre-installed and trusts. If every signature in the
chain checks out and the certificate hasn't expired or been revoked, the
browser now has strong reason to believe it's actually talking to the
real example.com — not an attacker in the middle, which is the exact
threat lesson 7 opened with.
The browser and server now perform a key exchange — modern TLS uses (Elliptic-curve) Diffie-Hellman (lesson 6) specifically for its forward secrecy property, generating a fresh shared secret for this connection alone. Neither side ever transmits this shared secret directly; each independently computes the same value from public messages exchanged during this step, exactly matching lesson 6's core idea.
Once both sides share a secret, every subsequent byte of the actual HTTP request and response is encrypted using fast symmetric encryption (lesson 2) — modern TLS specifically using an authenticated mode like GCM, so the connection gets both confidentiality (nobody can read the data) and integrity (any tampering is detected) in one mechanism, exactly as lesson 2 described.
Once this secure channel exists, whatever the application sends over it — a login form submission, a session cookie, an API request — is protected in transit by everything above. What happens to that data once it arrives is a separate concern this whole domain also built toward: a submitted password gets hashed with bcrypt or Argon2 (Auth's own lesson, building on this domain's lesson 1 and lesson 8's KDF concept) before ever touching a database; a session token or JWT gets signed with HMAC (lesson 5) or an asymmetric signature (lesson 4) before being trusted on a later request; any token or key generated along the way comes from a CSPRNG (lesson 9), never an ordinary random function.
Every lesson in this domain was one piece of this picture, deliberately separated out so each primitive could be understood on its own terms before being recombined here. Auth, Web Security, and Payments each use pieces of this constantly, quoting the results ("we use bcrypt," "we sign our JWTs," "TLS handles encryption") without needing to re-derive the mechanics each time — which is exactly the point of a fundamentals domain like this one: understand it once, deeply, and every practical application elsewhere in this curriculum becomes a specific instance of something already understood, rather than a new fact to memorize.
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. What happens immediately after a browser receives a server's TLS certificate during a handshake?
2. Why does modern TLS use a Diffie-Hellman-based key exchange rather than only encrypting a key with the server's public key?
3. Once a secure TLS channel is established, what still needs to happen with a submitted password?
Cryptography Fundamentals