HTTPS doesn't just add a padlock icon. It runs a cryptographic negotiation in under 50ms that makes your data unreadable to every router, ISP, and attacker between you and the server.
What's actually happening here?
When you connect to a site over HTTPS, your browser and the server run a handshake before any data moves. In that handshake they agree on a shared secret — a key that only they know — using a mathematical trick called asymmetric encryption. Every byte of actual data then travels encrypted with that shared secret using symmetric encryption, which is fast enough to handle real-time traffic. The padlock means this negotiation succeeded and the connection is authenticated and encrypted.
The problem this solves
HTTP sends everything as plain text. Every router your packet passes through — your home router, your ISP's infrastructure, the undersea cable operator's equipment — can read it. In 2010, a Firefox plugin called Firesheep let anyone on a coffee shop WiFi intercept Facebook sessions in one click. HTTPS makes intercepted data look like random noise. Even if an attacker captures every packet, they cannot read the content without the session key — and that key never travels across the network in readable form.
How it really works (step by step)
The TLS 1.3 handshake — from TCP connection to encrypted data in one round trip:
Client Hello — your browser sends supported cipher suites, a random nonce, and its half of a key exchange (a Diffie-Hellman public value). TLS 1.3 sends this in the very first message — no wasted round trips.
Server Hello + Certificate — the server picks the cipher suite, sends its own DH public value, and its certificate — a document signed by a trusted Certificate Authority proving it is actually
google.comand not an impostor.Key derivation — both sides independently compute the same shared secret using their DH values. This is the magic of Diffie-Hellman: two parties compute a shared secret without ever sending that secret over the wire. An eavesdropper who captured both DH public values still cannot derive the secret.
Session keys generated — the shared secret feeds into a key derivation function producing separate keys for client→server and server→client encryption. Asymmetric crypto is now done. Everything from here uses AES-256-GCM — a symmetric cipher that encrypts at multi-gigabyte-per-second speeds in hardware.
Certificate verified — your browser checks the server's certificate signature against its built-in list of trusted Certificate Authorities. If the chain is valid and the domain matches, the identity is confirmed.
Encrypted data flows — HTTP traffic now travels inside TLS records, each encrypted and authenticated with a message authentication code. Tampering with even one byte causes authentication failure and the connection drops.
The part most tutorials skip
TLS 1.3's most important security property is forward secrecy — and most engineers can't explain why it matters. In TLS 1.2 and earlier, some cipher suites used the server's long-term private key directly to encrypt the session key. If an attacker recorded years of encrypted traffic and then later obtained the server's private key — through a breach, a court order, or a vulnerability — they could decrypt every historical session retroactively.
TLS 1.3 mandates ephemeral Diffie-Hellman for every session. Each connection generates a fresh, temporary key pair that is discarded the moment the session ends. The server's long-term private key is used only for authentication — proving identity — never for encryption. Compromise the private key tomorrow and you learn nothing about sessions that happened today. This property is called Perfect Forward Secrecy, and it is the reason TLS 1.3 is not optional for any production system handling sensitive data.
Real company doing this right now
Cloudflare terminates TLS for millions of websites on its edge network — handling over 55 million HTTP requests per second at peak. Their challenge: TLS handshakes are CPU-intensive, and they cannot afford to forward every connection to an origin server for negotiation. Their solution is TLS termination at the edge: Cloudflare holds the TLS private keys for each customer's domain on its edge nodes, terminates the encrypted connection there, and forwards to the origin over a separate encrypted tunnel. In 2022 they open-sourced a technique called Geo Key Manager — allowing customers' private keys to be stored only in specific geographic regions, satisfying data sovereignty laws while still getting CDN performance benefits globally.
What breaks at scale?
Certificate expiry is the silent killer of production systems. Let's Encrypt certificates expire every 90 days. Manual renewal processes, forgotten cron jobs, and misconfigured automation have caused catastrophic outages at large companies — including a 2021 outage at a major Finnish health data provider and LinkedIn experiencing a certificate expiry incident. When a certificate expires, browsers show a full-page warning and most users abandon immediately. Worse, HSTS (HTTP Strict Transport Security) — a header that instructs browsers to refuse HTTP connections — means expired certificates cause hard failures with no HTTP fallback. The fix is automated certificate management (ACME protocol / Let's Encrypt) combined with monitoring that alerts at 30 days, 14 days, and 7 days remaining.
The "aha" moment
HTTPS protects data in transit — not at rest on the server. Once your encrypted request arrives and is decrypted by the server, the data is plain text inside their systems. Encryption in transit and encryption at rest are two separate, independent problems.
Your practical takeaway
Enable HSTS with a long max-age from day one — add
Strict-Transport-Security: max-age=31536000; includeSubDomainsto your responses. This instructs browsers to refuse HTTP connections to your domain for one year, even if they somehow land on an HTTP link. Submit to the HSTS preload list and browsers enforce this before the first connection.Automate certificate renewal with Certbot or your cloud provider's ACM — and monitor expiry separately — automation fails silently. Set up an independent expiry monitor (Uptime Robot, Checkly, or a simple cron that alerts) that checks the actual certificate expiry date via a TLS handshake, not just whether renewal ran.
Never use TLS 1.0 or 1.1 on any production system — both have known cryptographic vulnerabilities (POODLE, BEAST). Set your minimum to TLS 1.2 with only forward-secret cipher suites, and prefer TLS 1.3 where clients support it. Most cloud load balancers let you set this with one configuration line.
Lesson 11 · Stage 1 — Network Foundations · System Design Made Easy