Every "lock" in your browser bar means: there's a TLS-encrypted tunnel between you and the site, the site proved its identity with a certificate, and an attacker on the wire can see roughly where your traffic is going but not what's in it.
What TLS actually does
- Authenticates the server. The site presents a certificate signed by a Certificate Authority your browser trusts. The browser verifies the chain up to a root CA built into its trust store.
- Encrypts the channel. Symmetric keys are negotiated during the handshake; everything after is opaque to anyone watching the packets.
- Verifies integrity. Each packet is MAC'd. Tampering breaks the MAC and the connection drops.
The TLS 1.3 handshake
TLS 1.3 (RFC 8446, finalised 2018) cut the handshake from two round trips to one:
- ClientHello. Client sends a list of supported cipher suites, key-share values for likely-to-be-chosen groups, and the hostname it wants (the SNI extension).
- ServerHello + Certificate + Finished. Server picks a cipher, sends its certificate, derives the session keys, and signals "ready."
- Client Finished. Client verifies the certificate chain and derives the same session keys. From this point on, everything is encrypted.
That's one round-trip — handshake done in <100 ms across continents. With 0-RTT session resumption, repeat visits can send application data on the very first packet, at the cost of slightly weaker replay protection.
What's visible on the wire
TLS encrypts content. It does not encrypt all of the metadata. An on-path observer — your ISP, the coffee-shop Wi-Fi router, a state-level firewall — can see:
- Your IP and the server's IP (it's reading the IP header).
- The hostname you're connecting to (via the SNI extension in ClientHello).
- The size and timing of every packet (which leaks structural info about what you're doing — "this looks like a video stream").
SNI is the obvious leak. Encrypted Client Hello (ECH) — successor to the earlier ESNI — encrypts SNI so the observer only sees that you're talking to a generic CDN edge IP, not which specific hostname. Cloudflare deployed ECH at scale in 2023; Firefox enabled it in 2024.
Why "the certificate" matters so much
The whole authentication side of TLS rests on a CA having verified that the server operator controls the domain. If a CA mis-issues a cert, the entire trust model breaks. That's why:
- CAA records in DNS let you restrict which CAs can issue for your domain. Check yours with our DNS tool.
- Certificate Transparency requires every cert to be logged in append-only public logs. You can monitor for mis-issuance against your own domains.
- HSTS preloading hard-codes a domain's HTTPS-only status into browsers, so even a first visit can't be downgraded to HTTP.
Common confusions
- SSL vs. TLS. SSL 3.0 is dead (POODLE, 2014). Everything since is TLS, but the term "SSL certificate" stuck around in marketing copy and never went away.
- Port 443 vs. 80. 80 is plain HTTP, 443 is HTTP-over-TLS. Modern sites redirect 80 → 443 and add HSTS so the browser doesn't try 80 again for a long time.
- "Free Let's Encrypt certs" vs. paid CAs. Cryptographically identical; paid certs buy higher liability insurance + tooling for organisations that need it. IPFerret uses Let's Encrypt via Caddy.