HTTPS is just HTTP with a security layer bolted underneath. That layer is TLS (Transport Layer Security — the modern name for what people still call SSL). In simple language — TLS wraps the whole conversation in a locked box so nobody in the middle can read or tamper with it.
Why HTTPS at all
HTTPS gives us three guarantees. Worth memorizing the trio:
- Encryption — snoopers on the wire (coffee-shop wifi, your ISP) see gibberish, not your password.
- Integrity — if someone flips even one bit in transit, the receiver notices and rejects it. No silent tampering.
- Authentication — we’re actually talking to
bank.com, not an imposter pretending to be it.
Plain HTTP gives us none of these. That’s why browsers now shame every http:// site with a “Not Secure” badge.
Symmetric vs asymmetric — the two kinds of crypto
TLS uses both, and knowing the difference is the whole game.
Symmetric encryption — one shared secret key encrypts and decrypts. Fast. The catch: both sides need the same key, and shouting a secret key across the internet is obviously a bad idea.
Asymmetric encryption — a key pair: a public key and a private key. Anything locked with the public key can only be opened by the private key. The public key can be shared with the world; the private key never leaves the server. Slower, but it solves the “how do we agree on a secret over an open wire” problem.
Think of it like this: asymmetric is an expensive armored truck we use once to safely hand over a secret. Symmetric is the cheap fast car we use for every trip after that.
So TLS does both: use slow asymmetric crypto during the handshake just to agree on a shared symmetric key, then use fast symmetric crypto for the actual data. Best of both worlds.
The TLS handshake
This happens right after the TCP handshake, before any HTTP. Here’s the flow (simplified TLS 1.2-style so the steps are visible).
Step by step:
- ClientHello — client says “here are the TLS versions and cipher suites I speak” plus a random number.
- ServerHello — server picks a version and cipher, sends its own random number.
- Certificate — server sends its certificate, which contains its public key.
- Key exchange — using that public key (asymmetric), both sides securely agree on a shared secret, then derive matching symmetric session keys from it. Modern TLS 1.3 uses an ephemeral Diffie-Hellman exchange here so past traffic stays safe even if the private key later leaks (forward secrecy).
- Finished — both confirm, and every byte after this is encrypted with the fast symmetric keys.
TLS 1.3 trimmed this to a single round trip (and 0-RTT for resumed connections), so it’s noticeably faster than the older two-round-trip dance.
Certificates, CAs, and the chain of trust
A certificate is basically a signed ID card. It says “this public key belongs to bank.com” and it’s signed by a Certificate Authority (CA) — a trusted org like Let’s Encrypt or DigiCert.
But why trust the CA? Because our OS and browser ship with a built-in list of root CAs they trust. Here’s the clever part: CAs don’t sign your site directly with the precious root key. They sign intermediate certs, which sign your site’s cert. That’s the chain of trust.
The browser walks this chain upward. If it reaches a root it already trusts and every signature checks out, the cert is valid. If any link is broken, expired, or self-signed, we get the scary “Your connection is not private” page.
Interview soundbite
HTTPS = HTTP over TLS, giving us encryption, integrity, and authentication. TLS uses asymmetric crypto (a public/private key pair) during the handshake only, to agree on a fast symmetric session key used for the real data. The handshake goes ClientHello → ServerHello → Certificate → key exchange → session keys → encrypted traffic. We trust the server’s certificate because it chains up through intermediate CAs to a root CA our browser already trusts — that’s the chain of trust.