Plain HTTP is a postcard — everything travels as readable text, so anyone on the network path between you and the server can read it or quietly change it. HTTPS fixes both problems: it first checks the server's ID card (its certificate), then seals the rest of the conversation in an envelope only the two of you can open. That locked, verified channel is what the padlock in the address bar stands for.
Two kinds of key
The whole scheme rests on combining two forms of encryption, because each is good at what the other isn't.
1Asymmetric (public-key) — a *pair* of keys: a public key anyone may use and a private key only the owner holds. It's slow, but it solves the impossible-looking problem of agreeing on a secret with a stranger over an open wire.
2Symmetric — a *single* shared key that both scrambles and unscrambles. It's fast, so it protects the actual page traffic — but both sides must already share the key.
The best-of-both trick
HTTPS uses the slow asymmetric step *once* at the start, only to agree on a shared session key — then switches to fast symmetric encryption for all the real data. You get public-key's stranger-handshake ability with symmetric's speed.
The TLS handshake, in brief
Before any page data flows, browser and server run the TLS handshake — the setup behind the padlock.
1The browser says hello and lists the encryption methods it supports.
2The server replies with its certificate: a tamper-proof ID card naming the domain and carrying the server's public key.
3The browser verifies the certificate chain — that the certificate is signed by a Certificate Authority it trusts, matches the domain, and hasn't expired.
4The two sides run a key exchange to agree on a shared session key out in the open, without ever transmitting it.
5From here on, every message is encrypted with that session key using fast symmetric encryption.
The certificate proves identity, not secrecy
A certificate is an ID card, not a secret — it's meant to be handed out. It names the domain and holds the server's *public* key, and a Certificate Authority (CA) signs it to vouch that the domain really controls it. Your browser ships with a list of CAs it trusts, which is how it can trust a site it has never seen. The signatures linking the site's certificate up to a trusted CA are the certificate chain.
What an eavesdropper sees
Once the handshake finishes, the session key encrypts everything. Someone watching the wire sees only ciphertext — meaningless noise without the key. They can still tell *which server* you connected to (the destination IP, and the domain name in the TLS hello), but not *what* you sent or received. If the certificate fails to verify — wrong domain, expired, or an untrusted signer — the browser shows a full-page warning instead of the padlock, because identity can't be trusted.
The deeper TLS mechanics live in Networking
The exact key-exchange maths — how two parties agree on a shared secret over an open channel without pre-sharing anything — is Diffie-Hellman, covered in the Networking module. HTTPS is just HTTP carried inside that secured TLS channel; this lesson stays at the browser's-eye view of *why the padlock is trustworthy*.
OperationTimeSpace
Asymmetric (handshake) · used once, to agree on the session keyslow—
Symmetric (page traffic) · protects every message after the handshakefast—
Check yourself
Why does HTTPS use slow public-key crypto only during the handshake, then switch to a symmetric session key?
