HTTPS & TLS Explained: What the Padlock Actually Guarantees

Every previous attack in this guide happened at the endpoints — the browser, the server, the database. This chapter is about the wire between them, and the protocol that secures it: TLS, the thing that turns HTTP into HTTPS. This is OWASP's "cryptographic failures" category, and it's also the most misunderstood padlock on the internet.

The problem: the network is public

When a request leaves your laptop, it hops through your router, your ISP, several backbone networks, and the destination's infrastructure before arriving. At every hop, someone operates the equipment your data passes through. Over plain HTTP, all of it travels as readable text.

That means anyone positioned on the path — the coffee-shop Wi-Fi operator, a compromised router, an ISP, a nation-state — can do three distinct bad things, and it's worth separating them because HTTPS answers each one:

1. Read everything — passwords, messages, session cookies (a passive eavesdropper).
2. Tamper with content — inject ads, swap a download for malware, alter an amount (an active attacker).
3. Impersonate — pretend to be the server you meant to reach (a man-in-the-middle).

HTTPS exists to defeat all three, and maps onto three guarantees.

The three guarantees

Most people compress all three into "it's encrypted." Encryption is only the first. Without authentication, encryption is worthless — you'd have a perfectly private conversation with an impostor. The clever part of TLS is how it delivers the third guarantee, so let's build up to it.

The hybrid: two kinds of crypto, each for what it's good at

TLS has to solve a chicken-and-egg problem. To encrypt data efficiently, both sides need a shared secret key. But they're strangers on a public wire — how do they agree on a secret without an eavesdropper learning it?

The answer combines two families of cryptography:

• Symmetric encryption — one shared key both encrypts and decrypts. Fast, ideal for bulk data. Problem: both parties need the same key, and you can't safely send it over a public line.
• Public-key (asymmetric) encryption — a pair of keys, public and private. Anything scrambled with the public key can be unscrambled only with the private one. Slow, but solves key distribution: you can hand out the public key to anyone.

The insight: use slow public-key crypto once, to safely agree on a shared secret — then use fast symmetric crypto for everything after.

That's the TLS handshake, and buried in it is the identity check. (Modern TLS 1.3 doesn't literally encrypt-the-secret-to-the-public-key — it uses a Diffie-Hellman key agreement for forward secrecy — but the shape is the same: public-key math to establish a shared secret, symmetric crypto thereafter. The mental model holds.)

Certificates: solving "is this really the server?"

Agreeing on a secret with someone is easy. Agreeing with the right someone is the hard part — a man-in-the-middle could intercept the handshake and agree a secret with you, while pretending to be the bank. This is where the encryption-without-authentication trap would spring shut.

The fix is the certificate. When you connect, the server presents one — a document stating "the public key for example.com is this," which the browser uses for the key agreement. But a certificate is just a claim; anyone can generate one saying they're example.com. What makes it trustworthy is a signature.

This is why the man-in-the-middle fails: they can intercept your traffic, but they cannot produce a validly-signed certificate for example.com — no CA will sign one for a domain they don't control. Present an unsigned or mismatched certificate and the browser throws the full-page warning everyone's learned to fear. (The modern CA landscape is also free and automated — Let's Encrypt made "just use HTTPS" the default rather than a budget line.)

What the padlock does NOT mean

Now the crucial disclaimer, because this misconception causes real harm:

The padlock means the connection is encrypted and the certificate is valid. It says nothing about whether the site is trustworthy.

A phishing site at paypa1-secure.com can obtain a perfectly valid certificate for its own domain in minutes, for free, and show a flawless padlock. HTTPS faithfully guarantees you have a private, authenticated channel to paypa1-secure.com — which is exactly the scammer's site. The padlock verifies identity of the domain you're talking to, not the honesty of whoever owns that domain.

So "look for the padlock" is necessary but wildly insufficient advice. HTTPS secures the pipe; judging the site at the other end is a separate act. This is the transport-layer echo of the CORS chapter's lesson — a mechanism protecting one specific thing gets over-trusted to mean general safety.

HSTS: closing the downgrade window

One gap remains. You type example.com — no https://. Your browser's first request often goes out over plain HTTP, and the server redirects it to HTTPS. In that split second, an active network attacker can intercept the HTTP request and keep you on an attacker-controlled plaintext connection — an SSL-stripping attack. The upgrade never happens and you never notice.

HSTS (HTTP Strict Transport Security) closes it with a single response header:

Strict-Transport-Security: max-age=31536000; includeSubDomains

It tells the browser: for the next year, never contact this domain over anything but HTTPS — don't even send the initial HTTP request. After the first secure visit, the downgrade window is gone. Sites can even be preloaded into browsers so the very first visit is protected too. It's one header (covered alongside its siblings in the headers chapter) and it upgrades "we redirect to HTTPS" into "HTTP is not an option."

Recap

• HTTPS/TLS provides three guarantees — confidentiality, integrity, authentication — not just "encryption"; authentication is what makes the encryption meaningful.
• It defeats the on-path attacker's three moves: reading, tampering, impersonating.
• TLS is a hybrid: slow public-key crypto to authenticate and agree a shared secret once, fast symmetric crypto for the data.
• Certificates + CAs solve identity — a trusted authority signs the domain-to-key binding, and an impostor can't forge that signature.
• The padlock ≠ safe site — it proves an encrypted, authenticated channel to a domain, including a scammer's; judging the site is separate.
• HSTS forbids the HTTP downgrade, closing the SSL-stripping window that redirects alone leave open.

We've now touched several protective HTTP headers in passing — HSTS, CSP. It's time to meet the full set that hardens a site with almost no code. Continue to Security headers, explained.