Roughly 95 percent of web pages loaded in Chrome now travel over HTTPS, according to Google's transparency report - A complete reversal from a decade ago, when encrypted browsing was the exception. Every one of those connections runs the same choreography: a TLS handshake that takes milliseconds, authenticates the server, and agrees on keys no eavesdropper can learn. It's arguably the most successful cryptographic deployment in history. It's also widely misread - Because the padlock makes one narrow promise, and people hear a much bigger one.
HTTP, HTTPS, and what the S buys you
Plain HTTP sends everything - URLs, cookies, passwords, page contents - As readable text. Anyone positioned on the path can read it or, worse, rewrite it: the coffee-shop WiFi operator, a compromised router, your ISP, or an attacker running a fake hotspot.
HTTPS is the same HTTP protocol wrapped inside TLS (Transport Layer Security, successor to the retired SSL - The old name stubbornly survives in "SSL certificate"). TLS provides three guarantees for the connection:
- Confidentiality - Traffic is encrypted; observers see which server you connected to, but not the pages, forms, or credentials.
- Integrity - Traffic can't be silently modified; injected ads or altered downloads break the cryptographic seal.
- Authentication - The server proves, via its certificate, that it controls the domain you asked for. You're talking to the real passwordgenerator.now, not an impostor answering on its behalf.
That third one deserves precision: the certificate authenticates the domain, not the business. Which is exactly where the padlock's reputation outruns its meaning.
Inside a TLS 1.3 handshake
TLS 1.3 - Standardized as RFC 8446 in 2018 and now carrying the majority of web traffic - Streamlined the handshake to a single round trip:
- ClientHello. Your browser sends the protocol versions and cipher suites it supports, plus its half of a key exchange: an ephemeral public key (typically X25519 elliptic-curve Diffie–Hellman), generated fresh for this connection.
- ServerHello. The server picks a cipher suite, sends its own ephemeral public key, and - Already encrypted from this point - Its certificate and a signature proving it holds the certificate's private key.
- Keys, derived not sent. Both sides combine their own private value with the other's public value and independently compute the same shared secret. That secret never crosses the wire. From it, both derive the symmetric session keys.
- Encrypted traffic. Everything after flows through an AEAD cipher - TLS 1.3 permits only authenticated encryption: AES-128-GCM, AES-256-GCM, or ChaCha20-Poly1305. Our guide to AES-256 under the hood covers what happens inside that cipher.
Just as important is what TLS 1.3 removed. RSA key exchange, static Diffie–Hellman, CBC-mode ciphers, RC4, SHA-1, and compression are all gone - Decades of attack surface (BEAST, POODLE, and friends) amputated. Because every 1.3 connection uses ephemeral keys, forward secrecy is mandatory: an adversary who records your traffic today and steals the server's private key next year still can't decrypt the recording. There's also an optional 0-RTT mode that lets returning visitors send data with zero handshake delay, at the cost of a narrow replay risk - Which is why it's restricted to idempotent requests.
What a certificate actually proves
A TLS certificate is a signed statement from a certificate authority (CA): the holder of this private key controls this domain name. Your browser ships with a list of trusted CAs and verifies the signature chain automatically. Since Let's Encrypt began issuing free automated certificates in 2015, obtaining one takes minutes - Which democratized encryption and, inevitably, armed phishers too.
If you've ever opened a certificate file, you've seen a wall of characters between BEGIN CERTIFICATE markers - That's the binary certificate run through Base64 so it survives text-based handling; you can see how that encoding works (and that it's not encryption) with our Base64 encoder. Security tools also identify certificates by fingerprint - A hash of the whole thing you can reproduce with a SHA-256 generator.
The padlock answers one question only: "Is my connection to this exact domain private and unmodified?" It says nothing about whether the domain deserves your password.
What the padlock does - And doesn't - Tell you
| Claim | Does HTTPS guarantee it? |
|---|---|
| Nobody on the network can read my traffic | Yes |
| Traffic can't be tampered with in transit | Yes |
| I'm connected to the domain in the address bar | Yes |
| A recording of my session can't be decrypted later | Yes, under TLS 1.3 forward secrecy |
| The site is legitimate and not a scam | No - Phishing sites use valid HTTPS |
| The site will handle my data responsibly | No - The server reads everything you send |
| The domain isn't a look-alike (paypa1.com) | No - Verify the spelling yourself |
The bottom half of that table is where people get hurt. The Anti-Phishing Working Group has reported for years that the overwhelming majority of phishing sites serve valid HTTPS - The padlock is table stakes for criminals now, not a differentiator. Browsers have responded by quietly demoting the icon (Chrome replaced the padlock with a neutral "tune" icon in 2023) and instead warning loudly on the absence of HTTPS. The modern rule: treat a missing padlock as a hard stop, and treat a present one as merely the beginning of scrutiny - Our guide to spotting phishing sites covers the rest of that checklist, starting with reading the domain carefully.
And remember the boundary: TLS protects data in transit. Once your password arrives, the site decrypts and processes it - HTTPS says nothing about whether it's then hashed properly, stored in plaintext, or logged. Protection of data at rest is a different architecture entirely; that's the territory of zero-knowledge vault design, where even the receiving server can't read what you store.
Why this matters specifically for your passwords
Login forms are the crown jewels of web traffic. HTTPS is what makes the following true:
- Your password crosses hostile networks - Hotel WiFi, airport hotspots - Unreadable.
- Session cookies, which are your logged-in identity, can't be plucked off the air. (Pre-HTTPS, the Firesheep tool made hijacking Facebook sessions on open WiFi a one-click party trick in 2010.)
- A man-in-the-middle can't rewrite the login page to redirect your credentials, because tampering breaks the TLS integrity check.
What HTTPS cannot do is save you from sending your password to the wrong place voluntarily. TLS delivered securely to secure-login-account-verify.com is still a catastrophe. Domain vigilance plus unique per-site credentials remain your half of the deal - A browser-integrated manager helps with both, since it refuses to autofill on domains that don't match.
FAQ
Is HTTPS the same as SSL?
Functionally, people use the terms interchangeably, but technically SSL (Secure Sockets Layer) is the deprecated 1990s ancestor; every version of it is prohibited today. Modern connections use TLS 1.2 or, increasingly, TLS 1.3. "SSL certificate" is a fossilized marketing term - The certificates themselves are protocol-agnostic X.509 certificates.
Can my ISP see what I do on an HTTPS site?
It can see that you connected to a given domain - Via DNS lookups and the certificate exchange - Plus timing and traffic volume. It cannot see specific pages, search queries, form contents, or credentials. Encrypted DNS (DoH) and Encrypted Client Hello close progressively more of the remaining metadata leaks.
Does a padlock mean a website is safe to enter my password on?
No. It means your connection to that domain is encrypted and authenticated - Nothing about the domain's intent. Phishing sites overwhelmingly use valid HTTPS. Check that the domain is spelled exactly right, be suspicious of links that arrived by email or text, and let your password manager's domain matching act as a second opinion: if it won't autofill, ask why.
What's the difference between HTTPS and a VPN?
HTTPS encrypts your connection to each individual website, end to end between browser and server. A VPN encrypts all your traffic, but only between your device and the VPN provider's server - Beyond that point, traffic continues under whatever protection it already had. They stack: a VPN hides which sites you visit from local observers, while HTTPS keeps the content sealed the whole way.
Why do sites' certificates expire so often?
Certificate lifetimes have been deliberately shortened - Let's Encrypt issues 90-day certificates, and industry rules have pushed maximum validity down toward roughly a year, with shorter mandates coming. Short lifetimes limit the damage window if a private key is stolen and force automation, which in practice means fewer forgotten, insecure, expired-cert sites - The occasional "certificate expired" warning is the visible cost of that trade.