How HTTPS Actually Works
(4 Minutes) | How it Works, TLS Handshake, Evolution, and Why it Matters
Get our Architecture Patterns Playbook for FREE on newsletter signup:
Postman’s 2025 State of the API Report
Presented by Postman
Postman’s 2025 State of the API Report reveals a critical gap: 89% of developers use AI, but only 24% design APIs for AI agents. As AI agents become the new API consumers, security threats and collaboration challenges are mounting. The teams pulling ahead are building smarter foundations. Discover what separates AI-ready organizations from those that will stall.
How HTTPS Actually Works
How does your password stay private even on sketchy café Wi-Fi?
That’s HTTPS at work.
HTTPS wraps HTTP in encryption and identity checks so logins, payments, and APIs stay private and tamper-evident. It matters because without it, anyone on the network can read or alter what your users send and receive.
From HTTP to HTTPS
HTTP (Hypertext Transfer Protocol) launched as a simple, stateless way to exchange data on the web. It assumed a friendly network: requests and responses traveled in plain text, which made the early web easy to build; but also easy to eavesdrop on.
As the web took on logins, payments, and APIs, “plain text” became a liability. That set the stage for HTTPS, which layers encryption and authentication on top to make those same exchanges private and trustworthy.
How HTTPS Works
At its core, HTTPS is just HTTP running inside an encrypted tunnel provided by TLS (Transport Layer Security). TLS ensures three things every time your browser talks to a server:
Privacy → Data is encrypted so no one on the network can read it.
Integrity → Each message carries a cryptographic tag so tampering is detectable.
Authenticity → The browser verifies it’s really talking to the intended website, not an impostor.
The TLS Handshake
Before any data is exchanged, the browser and server perform a TLS handshake to agree on encryption settings and prove identities. Here’s how it works:
Client Hello → The browser proposes supported TLS versions and encryption methods.
Server Hello + Certificate → The server picks compatible settings and presents a certificate proving its identity.
Certificate Verification → The browser checks that the certificate is valid, trusted, and matches the domain.
Key Exchange → The browser and server each create temporary (ephemeral) key pairs and use them to generate a shared secret. This secret lets both sides agree on encryption keys without ever sending those keys over the network.
Session Keys Derived → Both sides take the shared secret from the key exchange and mix it with random values from the handshake to create matching session keys. These session keys are unique to that connection and are used to encrypt and decrypt all data sent.
Once this setup is complete, normal HTTP requests and responses flow inside the encrypted channel. Every byte (headers, cookies, body content, etc.) is wrapped in TLS records, which are authenticated and encrypted before being sent across the wire.
In short, HTTPS ensures that even on the most untrusted network your data remains private, unaltered, and verifiably sent to the right destination.
The Evolution of HTTPS
Early HTTPS solved one problem (privacy) but created several others. The first versions were clunky, slow, and easy to misconfigure. Redesigns were made and new technologies were released to reach the smooth, secure experience we expect today.
Heavy handshakes → SSL and early TLS took multiple network trips before encrypting anything, adding seconds of latency. Modern TLS 1.3 cut that to a single round trip.
Weak ciphers → Outdated algorithms like RC4 and RSA key exchange lacked forward secrecy, meaning a stolen key could expose past traffic. New suites like ECDHE and AES-GCM fix that.
Certificate headaches → Getting and renewing certificates was manual, expensive, and error-prone. Automation tools made it painless.
Mixed content → Sites often loaded secure pages but fetched scripts over HTTP, letting attackers slip in code. Browsers now block that by default.
In short, HTTPS evolved to become more refined and reliable over time. What began as a slow, error-prone layer of protection is now fast, reliable, and nearly invisible.
Why It Matters
HTTPS isn’t just a checkbox for compliance and security; it’s the layer that makes the web trustworthy. Every login, payment, and API call relies on it to stay private, authentic, and untampered.
Knowing how it works helps you spot what breaks it: expired certificates, outdated TLS, or mixed content.
These aren’t minor details, they’re what keep users safe and your service credible.
Subscribe to get simple-to-understand, visual, and engaging system design articles straight to your inbox:
Let's connect
During the key exchange, the client already has the public key - from the certificate - the client uses it to encrypt a symmetric key - sends it across - and the server uses its private key to decrypt the same.
I think this detail is captured in the diagram but not in the keys exchange section above.