HTTPS Explained: What the Padlock Actually Protects

That little padlock in your browser's address bar? Most people think it means "this site is safe." It doesn't. A phishing site can have a valid certificate and a green padlock. A page designed to steal your credit card details can run over a perfectly legit HTTPS connection. The padlock means one thing: your connection to whoever owns that domain is encrypted. That's it. Nothing about whether the person on the other end is honest. Developers ship HTTPS by default now. Most of us enabled it once, probably via a one-click option on our hosting provider, and never thought about what it actually guarantees. The assumptions we carry are often wrong, and wrong assumptions about security are worse than no assumptions at all. 🔓 What plain HTTP looks like on the wire HTTP is plaintext. Every header, every cookie, every form body you submit travels as readable text across every network hop between you and the server. The coffee shop router, your ISP, a compromised switch anywhere along the path. All of them can read everything. But here's the part people forget: they can also modify it in flight. ISPs have literally injected advertisements into plain HTTP pages. Governments have replaced download links with malware. This isn't theoretical. Look at what a plain HTTP request actually looks like to anyone watching: GET /account/settings HTTP/1.1 Host: example.com Cookie: session_id=a8f29bc4e1d7; user=arnav Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiYXJuYXYifQ... Your session token. Your auth header. Sitting there in the clear. Anyone on the network path just... reads it. 🛡️ The three things HTTPS gives you Most people remember only one of these. HTTPS provides three guarantees: - Confidentiality - an observer between you and the server sees ciphertext, not your data - Integrity - if anyone tampers with the data in transit, the receiver detects it and rejects the connection - Server authentication - you're talking to the real domain, not an impostor pretending to be your bank Integrity is the underrated one. It's what stops the ISP ad injection, the download link swaps, the script tag modifications. Modern TLS uses AEAD ciphers (AES-GCM or ChaCha20-Poly1305), which means encryption and integrity verification happen together. Tamper with a single byte and the whole thing fails. Not a warning. A hard failure. The handshake, briefly HTTPS is just HTTP carried inside a TLS connection. The TLS handshake deserves its own post (it's getting one), so here's the short version. The handshake does two jobs: authenticate the server using its certificate, and agree on a shared symmetric key that both sides will use for the actual data. Why symmetric? Because asymmetric cryptography (the public/private key stuff) is too slow for bulk traffic. So TLS uses asymmetric crypto to set up the key, then switches to fast symmetric encryption for everything after. TLS 1.3 completes this in a single round trip. TLS 1.2 needed two. That one-round-trip improvement matters more than it sounds when you're connecting to servers across an ocean. Certificates and trust, briefly This is also getting its own deep-dive post, so I'll keep it short. A certificate binds a public key to a domain name. It's signed by a certificate authority (CA) whose root certificate your OS or browser already trusts. So trust chains downward: root CA signs an intermediate, intermediate signs the site's cert, browser trusts the root, therefore trusts the chain. The thing that made HTTPS go from "ecommerce sites only" to universal was Let's Encrypt making certificates free and automated. Before that, certs cost money and required manual renewal. Now there's no excuse not to have one. And honestly, that's a good thing, even if it means phishing sites get certs too. 🚨 What HTTPS does not hide This is where most misunderstanding lives. HTTPS encrypts the content of your communication. It doesn't hide everything about your communication. Not even close. | Protected | Not protected | |---|---| | Request/response bodies | The domain you're visiting (leaks via SNI and DNS) | | Headers and cookies | The server's IP address | | URL paths and query strings | How much data you're transferring | | Form submissions | When and how often you connect | | API payloads | What the server does with your data after it arrives | Let me expand on the "not protected" column. The domain leaks. During the TLS handshake, the client sends the requested hostname in plaintext via a field called Server Name Indication (SNI). Your DNS queries also reveal which domain you're looking up, usually in plaintext too. Encrypted Client Hello (ECH) fixes the SNI leak and DNS-over-HTTPS fixes the DNS leak, but adoption is uneven. Most connections today still expose the domain. The server IP is visible. Obviously. You're sending packets to it. Traffic volume and timing. An observer can't read your messages, but they can see that you sent 4KB to a health insurance portal at 2am, then 200KB came back. Traffic analysis is a real discipline and it infers a lot from metadata alone. Transit only. Once your data reaches the server, it's plaintext there. The server operator sees everything. HTTPS is not end-to-end encryption in the Signal or WhatsApp sense. It's point-to-point. Your data is protected on the wire, but the endpoints can do whatever they want with it. Valid cert, malicious site. A certificate proves domain control. That's all. It says nothing about whether the operator is running a scam. So the padlock doesn't mean "safe." It means "encrypted connection to this domain." Completely different statement. Where it still goes wrong in practice Even with HTTPS deployed, things break: - Mixed content - one http:// script tag on an HTTPS page means an attacker can inject code through that unencrypted resource. Browsers block this now, but older pages still trip over it - Missing HSTS - without HTTP Strict Transport Security, a user's first request to your site goes over plain HTTP before the redirect to HTTPS happens. That first request is vulnerable to downgrade attacks. HSTS tells the browser "never use HTTP for this domain again" - Expired certificates - this is the single most common self-inflicted outage in this area. Your site goes down not because of an attack, but because someone forgot to renew the cert. Automate renewal. Seriously - TLS interception - corporate proxies and some antivirus software install their own root CA on your machine, then decrypt, inspect, and re-encrypt your traffic. It's technically legitimate because you (or your IT department) trusted that root CA. But it means your "encrypted" connection has a reader in the middle - Client-side trust decisions - if your app checks something security-relevant only in client-side JavaScript, an attacker just... skips that check. HTTPS doesn't help here. Server-side validation is the only kind that counts 📌 Takeaways - The padlock means "encrypted connection to this domain," not "this site is trustworthy" - HTTPS gives you three things: confidentiality, integrity, and server authentication. Integrity is the one people forget - The domain you visit, traffic size, and timing all leak despite encryption - HTTPS protects data in transit only. The server sees everything in plaintext once it arrives - Automate cert renewal and enable HSTS. These are the two cheapest wins you can deploy today Top comments (0)