The Short Answer
The padlock icon next to a URL means three things — and only three things:
- The connection between your browser and the server is encrypted.
- The data has not been tampered with in transit.
- The certificate proves the server owns the domain in your address bar.
That's it. It does not mean the site is safe. It does not mean the site is honest. It does not mean the operator is who you think they are. A phishing site at g00gle-login.com with a valid certificate gets the same padlock.
How TLS Works (Without the Maths)
When you connect to an HTTPS site:
- Hello. Your browser sends a "ClientHello" listing the cipher suites it supports.
- Certificate. The server replies with its certificate — a public key signed by a trusted Certificate Authority (CA).
- Verification. Your browser checks the certificate: is it signed by a CA we trust? Is it for the domain we asked for? Is it still valid?
- Key exchange. Browser and server use the certificate to negotiate a symmetric encryption key — used only for this session, often discarded afterwards (perfect forward secrecy).
- Encrypted traffic. All HTTP requests and responses from now on are encrypted with that session key.
The end result: even an attacker who can see every byte on the network sees only encrypted gibberish.
What HTTPS Protects Against
- Eavesdropping on public Wi-Fi.
- Tampering by ISPs (injecting ads, modifying pages).
- Session hijacking through stolen cookies on the wire.
- DNS hijacking that redirects users to the wrong IP — the certificate check catches the impostor.
What HTTPS Does Not Protect Against
- A malicious or compromised website. HTTPS makes phishing pages just as encrypted as legitimate ones.
- A compromised server. Once data reaches the server, the server can do whatever it wants with it.
- Malware on your device. HTTPS protects the network, not your endpoint.
- A misconfigured server (weak ciphers, expired certs, mixed content).
Certificate Authorities and the Trust Chain
Browsers ship with a list of trusted root CAs. A site's certificate is valid only if it can be traced back to one of those roots. The chain typically looks like:
Your site cert → Intermediate CA → Root CA (in browser trust store)
If any link breaks (expired, untrusted issuer), the browser displays a warning.
CAs have failed in the past. DigiNotar (2011) was compromised and used to issue fake Google certificates. Symantec lost browser trust in 2018 due to repeated mis-issuance. The system is not perfect — but the alternative is unencrypted traffic, which is worse.
TLS 1.2 vs TLS 1.3
- TLS 1.0 / 1.1: deprecated since 2020. Major browsers refuse them.
- TLS 1.2: still widely used, secure if configured correctly.
- TLS 1.3: faster (one-round-trip handshake) and removes legacy cipher suites entirely. Use 1.3 if both client and server support it.
Common Mistakes Site Operators Make
| Mistake | Consequence |
|---|---|
| Letting the certificate expire | Visitors get a scary browser warning |
| Mixing HTTP and HTTPS resources | "Mixed content" warning, broken padlock |
| Using a weak cipher suite | Vulnerable to known cryptographic attacks |
| Not enabling HSTS | First visit can be downgraded to HTTP |
| Not redirecting HTTP to HTTPS | Some users land on the unencrypted version |
How to Check a Site
Visit ssllabs.com/ssltest and enter the domain. It will grade the TLS configuration and list every weak cipher, missing best practice, and configuration bug. Aiming for an A or A+ takes an afternoon and lasts for years.
Summary
HTTPS is a baseline, not a guarantee. It protects the path your data takes — but says nothing about the trustworthiness of the destination. Combine the padlock with attention to the actual domain name, awareness of phishing tactics, and a healthy scepticism about unsolicited links.