The TLS Foundation

Imagine sending a postcard through the mail. Anyone who touches it along the way — the postal worker at pickup, the sorter, the carrier — can read the back. That’s the regular internet without TLS.

Now imagine you slip that postcard into a locked metal box, and only the person you’re sending it to has the key. Even if someone steals the box on the way, they can’t see inside. That’s TLS.

This post is the foundation. No OpenSSL, no hands-on. By the end you’ll know what TLS actually does, how your browser decides who to trust, what really gets shipped with every operating system on earth, and why the whole system rests on one mathematical asymmetry. Each section is two minutes — read top to bottom.

What We’ll Cover

1. TLS in one image
2. The three jobs TLS does
3. How you know it’s on
4. SSL vs TLS — the name confusion
5. How authentication works — the chain of trust
6. The TLS handshake, step by step
7. Two crypto types, two jobs
8. What your browser actually ships
9. The asymmetry that makes everything work

1. TLS in One Image

Without TLS, your data on the internet is a postcard. The mailman reads it. The sorting worker reads it. Anyone with access to the path between you and the destination reads it.

With TLS, the postcard is inside a locked metal box. The recipient holds the only matching key. The carriers along the way still move the box from sender to receiver, but it’s opaque to all of them.

That’s the picture. Everything below is the mechanics that make the box work over a network — without you ever physically meeting the recipient to hand them a key.

2. The Three Jobs TLS Does

TLS does exactly three things when your computer talks to a server:

Encryption is the easy half. Both ends agree on a scrambling rule and use it. The genuinely hard half is authentication — knowing that the “recipient” on the other end of the wire is really who they claim to be. Everything else in this post is in service of that one problem.

3. How You Know It’s On

You don’t have to read the protocol to know TLS is working. Your browser tells you:

• 🔒 padlock icon + https:// — TLS is on. The conversation is encrypted and the server’s identity has been verified.
• ⚠️ “Not secure” + http:// — no TLS. Anyone in the path can read and modify the traffic.

The “S” in HTTPS literally stands for Secure. It means TLS is doing the work underneath HTTP. When your browser shows a green padlock, three things have already happened in the background: a certificate was checked, a key was negotiated, and traffic switched to encrypted mode. The rest of this post is how.

4. SSL vs TLS — The Name Confusion

You’ll see both names. They refer to the same thing in different generations.

• SSL was the original (1990s). The last version, SSL 3.0, had real vulnerabilities and has been retired for years.
• TLS replaced it. Current versions are TLS 1.2 (2008) and TLS 1.3 (2018, what almost everything uses now).

People still say “SSL” out of habit — the way people still say “Kleenex” for any tissue. If a vendor sells you an “SSL certificate” in 2026, it’s a TLS certificate. The name lags; the protocol moved on.

5. How Authentication Works — The Chain of Trust

This is the heart of TLS. How does your browser, dialing bank.example.com, know it’s actually talking to the bank and not a lookalike server set up by an attacker on the same Wi-Fi?

The answer is a chain of trust. Your browser and operating system ship with a pre-installed list of root certificates — DigiCert, Let’s Encrypt, GoDaddy, and roughly 150 others. This list is called the trust store. Every site’s identity ultimately anchors back to one of these roots.

But sites are not signed directly by root CAs. Roots sit offline in physical vaults; they sign intermediate CAs, and intermediates do the day-to-day work of signing real websites.

When you visit example.com, the server sends back its own certificate plus any intermediate certificates needed to complete the chain. Your browser walks the chain upward — leaf → intermediate → root — verifying each signature, until it lands on a root it already trusts.

Why the extra layer? If a root CA’s private key ever leaked, every certificate that CA had ever signed would have to be invalidated overnight. Keeping roots offline and using intermediates for daily signing means a compromised intermediate can be revoked without burning down the entire trust tree. The system is built to survive partial compromise.

6. The TLS Handshake, Step by Step

Here’s what actually happens in the first ~100 milliseconds when your browser opens an HTTPS site:

In words:

1. ClientHello — your browser tells the server which TLS versions and cipher suites it supports, plus a random number.
2. ServerHello + Certificate — the server picks a version and cipher, sends its random number, and sends its full certificate chain.
3. Verify the cert — your browser walks the chain. Is the signature valid? Is the cert in date? Does the name in the cert match the hostname you typed? Has it been revoked (OCSP or CRL)? If anything fails, you get the “not secure” warning.
4. Key exchange — both sides run a Diffie-Hellman exchange. The clever property: both ends arrive at the same shared secret key, but the key itself never travels across the wire. Even an attacker recording every byte cannot derive it.
5. Switch to symmetric — both sides now hold the same key. They abandon the slow asymmetric crypto and switch to fast symmetric encryption (AES) for the actual data.

Steps 1–4 are the handshake. Step 5 is the encrypted conversation. The handshake takes a handful of milliseconds and happens once per connection.

7. Two Crypto Types, Two Jobs

That last point matters more than it sounds. TLS uses two different kinds of cryptography, each for what it’s good at.

Asymmetric crypto has the magic property that a public key can verify what a private key signed — that’s how identity works. But it’s slow and expensive. Symmetric crypto is fast and cheap, but both sides need the same key — which is exactly the problem the asymmetric handshake just solved.

TLS uses the slow, identity-friendly half to bootstrap the fast, bulk-data-friendly half. Identity first, throughput second.

8. What Your Browser Actually Ships

A natural question after all this: if my OS and browser ship with DigiCert and Let’s Encrypt and GoDaddy “certificates,” does that mean those companies handed over their secrets to be embedded in every Chrome install on earth?

No — and this is the most important idea in public-key cryptography.

What’s shipped is each CA’s public key, inside a public certificate. The private key never leaves the CA. It sits in a hardware security module, in a vault, often requiring multiple people to access.

Anyone with the public key can verify a signature. Nobody, even with the public key, can forge one without the matching private key. It’s a one-way street.

Think of a medieval king’s wax seal. The king has a unique signet ring — that’s the private key, kept under guard. Everyone in the kingdom knows what the king’s seal looks like — that’s the public key, shared openly. When a letter arrives with the seal pressed into the wax, anyone can verify it’s authentic. But nobody can forge the seal without the ring.

Shipping CA public keys to every browser is the same trick: teaching every device in the world what the seal looks like, without ever risking the ring.

9. The Asymmetry That Makes Everything Work

Strip TLS down to the one idea you’d keep if you forgot everything else:

• Public keys are everywhere. They verify. Losing one costs nothing.
• Private keys are nowhere except where they belong. They sign. Losing one is catastrophic.

That asymmetry — verify-with-public, sign-with-private — is the cryptographic primitive underneath TLS, SSH, code signing, package signing, and every crypto wallet you’ve ever heard of. The protocols differ; the underlying trick is the same one.

When you see the padlock in your browser, what it really represents is: the server proved it holds a private key whose public half is signed by someone my browser already trusts. That one sentence is the whole foundation.

What You Have Now

You now have the mental model. Everything else — internal CAs, certificate transparency, mTLS, OCSP stapling — is variation on these same themes.

Next Steps

• Self-Host Harbor Image Registry on Debian — apply this. Build your own CA, sign certs for an internal registry, and wire it into a GitLab Runner end-to-end.
• Linux Server Security Baseline — if you become your own CA, the host that holds the private key is now the most powerful machine on your network. Harden it like it.