Every time you log into a website, something remarkable is happening in the background. Your browser and a server somewhere are agreeing on a secret, exchanging cryptographic proofs of identity, and setting up an encrypted channel, all before a single byte of your password travels across the wire. The whole ceremony takes under 100 milliseconds. Most people never think about it, and honestly, that’s the point.
But if you work in tech and don’t have a deep background in security, the mechanics can feel like a black box. This is my attempt to crack it open.
THE TWO FLAVORS OF ENCRYPTION
There are two fundamentally different ways to encrypt data, and understanding both is the entry point to everything else.
SYMMETRIC ENCRYPTION is the simple case: the same key locks and unlocks the data. It’s fast, it’s efficient, and it works great once both parties share the key.
The problem is getting that key to the other party in the first place. If you encrypt a message with a key and then send both the message and the key together, you’ve accomplished nothing. It’s like mailing someone a locked box and taping the key to the outside.
ASYMMETRIC ENCRYPTION solves this with a clever trick: two mathematically linked keys, one public and one private. Anything encrypted with the public key can only be decrypted with the private key. Think of it like a padlock that anyone can snap shut but only you can open. You hand out open padlocks to everyone; they lock their messages; only you, with the one private key, can open them.
Your private key never leaves your machine. That’s the whole point.
Asymmetric encryption has a cost though. It’s computationally expensive, making it impractical for encrypting entire conversations. So in practice, the two flavors work together: asymmetric encryption handles the handshake and key exchange, then both parties switch to symmetric encryption for the actual data. You get security for the setup and speed for everything after.
HOW TLS ACTUALLY WORKS
TLS (Transport Layer Security) is the protocol that implements this hybrid approach for the web. When your browser connects to a server over HTTPS, it runs a TLS handshake before any application data moves.
In TLS 1.3 (finalized in RFC 8446 in 2018), the handshake is surprisingly lean. The client sends a hello message that includes which cipher suites it supports and its own key share for a key agreement algorithm.
The server responds with its key share, its certificate, and a digital signature. Both sides can now independently compute the same shared secret without ever transmitting it directly.
From that point on, everything travels under that shared symmetric key.
What TLS 1.3 removed is almost as interesting as what it added. The previous version (1.2) supported dozens of cipher suites, many with known weaknesses, because removing them would have broken backward compatibility. TLS 1.3 deleted all of them.
You get five strong, modern cipher suites and nothing else. The handshake dropped from three round trips to one, and for resuming a known connection, it can reach zero.
There’s also forward secrecy, which I think gets less attention than it deserves. Consider the “harvest now, decrypt later” attack: an adversary records your encrypted traffic today and decrypts it years from now once they have more computing power.
TLS 1.3 defends against this by using ephemeral keys. Each session generates a fresh key pair, so even if your server’s private key leaks someday, old sessions stay private. Forward secrecy is mandatory in TLS 1.3, not optional.
THE CERTIFICATE PROBLEM
Here’s what TLS alone doesn’t solve: how do you know the server you’re talking to is actually who they claim to be?
Asymmetric encryption guarantees the channel is private. It says nothing about whether you’re talking to the right server. A person-in-the-middle attacker could intercept your connection, present their own public key instead of the real server’s key, and decrypt everything while forwarding it along. The data would still be “encrypted,” just not to the party you intended.
Certificates are the answer. A TLS certificate is a signed document that says “this public key belongs to this domain name.” Your browser receives the certificate, checks the signature, and only then proceeds with the key exchange. The signature makes forgery hard: you can’t produce a valid one without the private key of whoever signed it.
Think of a certificate like a notarized letter. The notary doesn’t vouch for the contents; they vouch for the identity of the person who wrote it. A CA does the same for a domain and its public key.
The signing party is a Certificate Authority (CA). Browsers and operating systems ship with a pre-approved list of CAs, each one vetted through rigorous audits. When a CA signs a certificate, they attest that they verified the domain owner actually controls that domain.
For basic domain validation, the CA automates this: it asks you to prove control by placing a specific file or DNS record somewhere only you could place it. More thorough extended validation certs require checking organizational identity as well.
THE CHAIN OF TRUST
Certificate Authorities don’t typically sign certificates directly with their most sensitive root certificate. They operate a chain instead.
The root CA certificate sits at the top. It’s self-signed (there’s no higher authority to sign it), and it lives inside browsers and operating systems. Apple ships a list, Mozilla ships a list, Microsoft ships a list.
Getting onto those lists requires passing strict, recurring audits. The root certificate’s private key stays offline, often in a physical vault, because any compromise would cascade down to every certificate signed beneath it.
Below the root sit intermediate CA certificates, which sign the actual leaf certificates that web servers present. This adds a safety buffer: if an intermediate gets compromised, the CA revokes it and issues a new one without disturbing the root. The chain goes root to intermediate to leaf.
When your browser validates a certificate, it walks up that chain until it reaches a root it already trusts. Every signature along the way must be valid and unrevoked. If the chain is intact, the certificate passes.
What I find worth sitting with is how much trust you’re implicitly delegating. You trust your browser vendor to curate a good root store. You trust each CA in that store to run tight operations and only issue certificates to legitimate domain owners. You trust the intermediates they’ve delegated to.
Every HTTPS padlock is the end result of decisions made by people you’ve never heard of in organizations you’ve never thought about. That’s not a flaw. It’s just what trust looks like at internet scale.
WHERE THIS IS HEADING
The current system has held up well, but two pressures are reshaping it.
The first is quantum computing. Algorithms like RSA and Elliptic Curve Cryptography (ECC) power today’s key exchange and certificate signatures, and they’re mathematically vulnerable to sufficiently powerful quantum computers. NIST finalized the first three post-quantum cryptographic standards in August 2024.
Browser vendors and major CDNs have started deploying hybrid key agreements that run classical and post-quantum algorithms in parallel. Traffic stays protected even if one approach turns out to be broken.
The second pressure is that “harvest now, decrypt later” threat again. Even if quantum computers capable of cracking RSA are years away, adversaries recording today’s traffic could theoretically decrypt it then.
That urgency pushed post-quantum adoption faster than most people expected. By late 2025, Cloudflare reported more than half of human-initiated web traffic through their network already used post-quantum key agreement.
The migration isn’t coming. It’s happening.
THE AI WRINKLE. Every API call to a large language model travels over TLS. Every prompt you send, every response you get back, every fine-tuning dataset you upload. The explosion of AI services has made encryption infrastructure more load-bearing than ever, because the data flowing through these channels is often sensitive: proprietary code, medical questions, financial analysis, personal conversations.
When you call an AI API, you’re trusting the same certificate chain described above to keep your prompts private in transit. But the “harvest now, decrypt later” threat hits differently here. Someone recording your encrypted API traffic today isn’t just capturing web browsing. They’re capturing the questions you asked an AI and the answers it gave, which together can reveal more about your thinking than either alone.
That’s a strong argument for why post-quantum TLS adoption matters now, not later.
There’s also a newer question: how do you verify that the AI on the other end is running the model it claims to be running? TLS proves the server’s identity, but it says nothing about what software is actually processing your data once it arrives.
Attestation protocols and confidential computing are starting to fill that gap, extending the chain of trust from “I’m talking to the right server” to “the right code is running on that server.” It’s early, but it’s the logical next link in the chain.
The trust infrastructure is holding. The cryptography is getting stronger. And most of it still happens in under 100 milliseconds, invisible to everyone.
T.
References
-
What happens in a TLS handshake? | Cloudflare - Breakdown of each TLS handshake phase, covering key exchange, server authentication, and session key derivation.
-
State of the post-quantum Internet in 2025 | Cloudflare Blog - Cloudflare’s report on post-quantum adoption, including traffic statistics and deployment progress for hybrid ML-KEM.
-
RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 | IETF - The authoritative TLS 1.3 specification, covering the handshake protocol, cipher suite requirements, and forward secrecy.
-
NIST Releases First 3 Finalized Post-Quantum Encryption Standards | NIST - Official announcement of the first standardized post-quantum algorithms and the timeline for deprecating RSA and ECC.
-
Certificate Chain of Trust | Keyfactor - How root CAs, intermediate CAs, and leaf certificates form the chain that browsers validate during HTTPS connections.