The padlock icon in a browser's address bar represents a real cryptographic process — understanding it clarifies exactly what HTTPS protects against, and what it was never designed to protect against at all.
What TLS actually establishes
TLS (Transport Layer Security, what HTTPS runs on top of) establishes two things for a connection: encryption (nobody in between can read the traffic) and authentication (you're actually talking to who you think you are, not an impersonator).
Certificates: proving identity, not honesty
A TLS certificate is issued by a Certificate Authority (CA) after verifying that whoever requested it actually controls the domain — the certificate then lets anyone visiting that domain verify its authenticity without contacting the CA directly, using cryptographic signatures.
Certificate for: devfieldguide.com
Issued by: (a trusted Certificate Authority)
Valid: 2026-01-01 to 2026-04-01
Public key: (used to establish the encrypted session)
This is the important nuance: a CA verifies domain control, not the intentions of whoever controls it — a convincing phishing site on a freshly registered domain can have entirely valid HTTPS. The padlock means "this connection is encrypted and this really is the domain in the address bar," not "this site is safe to trust."
Symmetric vs. asymmetric: why both are used
TLS uses asymmetric cryptography (a public/private key pair) only briefly, during the handshake, to securely agree on a symmetric key — then switches to symmetric encryption for the actual data transfer, because it's dramatically faster:
Asymmetric (handshake only): slow, but solves "how do two strangers agree
on a secret without an eavesdropper learning it"
Symmetric (the actual traffic): fast, used once both sides share a secret key
This hybrid approach is why TLS handshakes have a small one-time cost per connection, but the actual data transfer afterward is fast — connection reuse (keep-alive, HTTP/2 multiplexing) exists specifically to amortize that handshake cost across many requests.
What HTTPS protects against
- Eavesdropping — someone on the same network (public Wi-Fi, a compromised router) reading your traffic in plain text.
- Tampering — an intermediary modifying data in transit (injecting ads, altering a downloaded file) without detection.
- Impersonation — a fake server pretending to be the real one, which certificate verification is specifically designed to catch.
What HTTPS does not protect against
- A malicious or compromised website itself. HTTPS secures the connection, not the code or intent running at the other end.
- Phishing via a legitimate-looking but different domain.
paypa1.com(with a "1" instead of "l") can have perfectly valid HTTPS — the padlock verifies that exact domain, not that it's the domain you meant to visit. - Client-side vulnerabilities — XSS, malicious browser extensions, or a compromised endpoint device are entirely outside what TLS covers.
HSTS: forcing HTTPS, permanently
Strict-Transport-Security is a header that tells the browser to never attempt an unencrypted HTTP connection to this domain again, even if a user types http:// explicitly or clicks an old HTTP link:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preloadWithout HSTS, a user's very first request to a domain could still go out over plain HTTP before any redirect to HTTPS happens — a real, if brief, window for an attacker on the same network to intercept that first request. HSTS closes that window for every subsequent visit within the max-age period.
TLS versions: why "TLS 1.2 or higher" matters
TLS has had several versions, and older ones have known, real weaknesses — TLS 1.0 and 1.1 are deprecated by major browsers and standards bodies specifically because of documented cryptographic vulnerabilities, not just for being outdated:
TLS 1.0 / 1.1 — deprecated, vulnerable to several documented attacks (BEAST, POODLE downgrade)
TLS 1.2 — still widely used, secure when configured with modern cipher suites
TLS 1.3 — current, simplified handshake, removes several legacy weak options entirely
A server that still accepts TLS 1.0/1.1 connections isn't automatically compromised, but it's accepting weaker security by default — modern server configuration should specify a minimum of TLS 1.2, ideally defaulting to 1.3 where client support allows.
Certificate pinning: going beyond default trust
For especially sensitive applications (banking apps, anything handling high-value transactions), certificate pinning hardcodes which specific certificate (or public key) is expected, rejecting connections even if a technically valid certificate from a different, compromised, or unexpected CA is presented:
Normal TLS: trust any certificate signed by any CA the OS/browser already trusts
Pinned TLS: trust only this specific certificate/key, reject anything else
This defends against a scenario normal TLS doesn't fully cover — a compromised or coerced Certificate Authority issuing a fraudulent-but-technically-valid certificate for your domain. It's a real tradeoff (pinning wrong, or forgetting to update a pin before a legitimate certificate rotation, can break the app entirely), which is why it's reserved for genuinely high-value targets rather than applied universally.
Common mistakes
- Treating "has HTTPS" as equivalent to "is safe to trust." Certificate issuance verifies domain control, not the legitimacy or safety of the content — a convincing phishing page can be fully HTTPS-secured.
- Ignoring a certificate warning because "it's probably fine." A warning almost always means either a genuine misconfiguration or an active interception attempt — neither is safe to click past casually.
- Serving mixed content — an HTTPS page loading some resources over plain HTTP. Modern browsers block or warn on this specifically because it reintroduces exactly the interception risk HTTPS exists to close.
- Not setting HSTS, leaving a real (if narrow) window on a user's first visit where an unencrypted request could still be intercepted before any redirect to HTTPS occurs.
Related reading
- OWASP Top 10, Explained for Developers Who Aren't Security Specialists — shares tags: cybersecurity, web-development (same category).
- Two-Factor Authentication: How It Actually Works — shares tags: cybersecurity.
- Android App Permissions: A User's Guide to Staying Safe — shares tags: cybersecurity.
- Understanding iOS App Permissions and Privacy Labels — shares tags: cybersecurity.
- HTTP Caching Explained: Cache-Control, ETags, and CDNs — shares tags: web-development.
