SSL / TLS — how the internet keeps secrets

That little padlock in your browser bar hides one of the slickest pieces of engineering on the whole internet. Here's what it's actually doing back there.

SSL, TLS — what's the difference?

SSL (Secure Sockets Layer) came first. TLS (Transport Layer Security) replaced it years ago. These days everyone still says "SSL" out of habit, but what they mean is TLS — usually 1.2 or 1.3, the only two versions still safe to use.

Three problems TLS solves

Confidentiality

Nobody in the middle can read your data. The only two who ever see the plain text are you and the server — everyone in between just sees noise.

Integrity

Nobody in the middle can quietly change the data either. If someone tries, TLS spots it and drops the connection on the spot.

Authenticity

You're genuinely talking to the server you think you are, not a look-alike. Certificates are what prove it.

The TLS handshake (1.2, simplified)

TLS 1.2 handshake — establishing a secure channel
Client Server 1. ClientHello — cipher list, random nonce 2. ServerHello + certificate + public key 3. Verify cert · send pre-master (encrypted w/ server pubkey) Both sides derive the same session key from the pre-master + nonces 4. Finished (first message encrypted with session key) 5. Finished (encrypted) All further application traffic uses the shared session key (symmetric).
Two round trips in TLS 1.2 — one in TLS 1.3, and 0-RTT for resumed sessions.

Symmetric vs asymmetric — and why TLS uses both

Asymmetric crypto — the public/private key pair — is slow, but it's brilliant at getting a secret between two strangers who've never met. Symmetric crypto — one shared key — is fast, but it only works if both sides already hold the same key.

So TLS leans on asymmetric crypto just once, during the handshake, to agree on a shared session key. After that it switches to fast symmetric crypto for everything else. You get the strengths of both and the weaknesses of neither.

Locked box, shared key

Say you want to send someone a secret. Their public key is a padlock only their private key can open. You use it just once — to ship them a shared key inside a locked box only they can open. Now you both hold the same key, and every message from there on rides on that (much faster) shared key.

Certificates — proving identity

A TLS certificate is really just a signed statement: "whoever holds this private key is example.com." The signature comes from a Certificate Authority (CA) your browser already trusts. Your browser ships with a list of around 150 trusted root CAs, and anything they sign — or anything signed by someone they signed — is trusted right down the chain.

The chain of trust
Root CA e.g. ISRG Root X1 Intermediate CA e.g. Let's Encrypt R3 Leaf cert for example.com signs signs Trust starts at the root, which is pre-installed in your OS/browser.

Getting a certificate

For years you had to pay for a cert. Now Let's Encrypt hands them out for free over the ACME protocol, and tools like certbot, acme.sh, Caddy, Traefik, and cert-manager (over in Kubernetes) automate the entire dance for you — right down to renewing every 90 days.

# Get + auto-install a cert on a running nginx
certbot --nginx -d example.com -d www.example.com

TLS 1.3 — what changed

  • Handshake shrunk to 1 round trip (0-RTT for resumed sessions).
  • All broken ciphers removed. Only modern, forward-secret cipher suites remain.
  • Everything after the ServerHello is encrypted — even the certificate.
Turn on TLS 1.3, disable 1.0/1.1

Any modern reverse proxy flips this with a single line of config. TLS 1.0 and 1.1 are officially dead — every major browser has dropped them — so leaving them switched on is just a compliance-and-security foot-gun waiting to go off.

HSTS — force HTTPS

The Strict-Transport-Security response header tells the browser one thing: "from now on, only ever reach me over HTTPS." Once the browser remembers that, any attempt to hit http:// gets upgraded automatically, before a single request leaves the machine. Add it once your site is fully on HTTPS — not before.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Try it yourself

# See the certificate chain a site presents
openssl s_client -connect example.com:443 -servername example.com < /dev/null

# See when a cert expires
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

# Grade a public site
# https://www.ssllabs.com/ssltest/
Never ignore cert warnings

A browser cert warning almost always means one of three things: the cert has expired, the domain on it doesn't match the site, or someone's sitting in the middle of the connection. Not one of those is safe to click past on a production site.

For the support team — "your connection is not private"

When a customer hits "Your connection is not private" (Chrome) or "Warning: Potential Security Risk" (Firefox), the number-one cause is a cert that quietly expired — Let's Encrypt certs last 90 days, and the auto-renew didn't fire. Confirm it in seconds: echo | openssl s_client -connect thedomain.com:443 2>/dev/null | openssl x509 -noout -dates and read the notAfter date. If it's in the past, renew (certbot renew, then reload the web server) and you're done. The other usual suspects: the cert doesn't cover the exact hostname the customer typed (cert is for example.com but they went to www.example.com), or the server is handing back the wrong cert entirely. Check the real dates before assuming anything scarier is going on.

Key takeaways

  • TLS gives confidentiality, integrity, and authenticity — the padlock trio.
  • The handshake uses asymmetric crypto to agree on a symmetric session key.
  • Certificates prove identity through a chain of trust rooted in CAs your OS trusts.
  • Use TLS 1.2 or 1.3; disable older versions. Certificates are free (Let's Encrypt).
  • HSTS locks browsers to HTTPS after their first visit.