What Is This?
Every time your browser connects to a website over HTTPS, something remarkable happens in roughly 50 milliseconds. Two computers that have never communicated before — separated by an adversarial network where anyone can intercept packets — negotiate a shared secret that neither transmits, verify each other's identities without a shared password, and establish an encrypted channel that a nation-state with a room full of computers cannot feasibly break. Then they start sending your data.
This is TLS — Transport Layer Security. The successor to SSL (Secure Sockets Layer, deprecated after years of critical vulnerabilities). The current version, TLS 1.3, was finalised in RFC 8446 in 2018. It runs underneath HTTPS, but also underneath email (SMTP/IMAP with STARTTLS), VPNs, instant messaging, APIs, and most secure internet communication you ever do.
Most builders use TLS without understanding it. They follow the HTTPS setup guide, let their certificate auto-renew, and move on. This is understandable — TLS is designed to be invisible when it works. The problem is that when something goes wrong — a certificate error, an unexpected TLS handshake failure, a subtle MITM vulnerability in an API integration — understanding the mechanism is the difference between a 30-second fix and a 3-hour debug spiral. And as vibe coders shipping production systems, the attack surfaces you implicitly accept when you misconfigure TLS are real.
The problem TLS solves:
Networks are adversarial by design. Between your computer and any server, packets pass through routers, ISPs, potentially hostile network infrastructure, and any number of potential eavesdroppers. If you send a password over plain HTTP, anyone intercepting that packet can read it. TLS provides three properties:
- Confidentiality — the data is encrypted; interceptors see ciphertext
- Authentication — you know you're talking to the server you think you are, not an impersonator
- Integrity — the data hasn't been tampered with in transit
All three simultaneously, every connection, for free from the user's perspective.
How the TLS 1.3 handshake actually works:
The handshake is the negotiation phase before any application data is sent. In TLS 1.3, it completes in a single round trip:
Step 1 — Client Hello: Your browser sends to the server: the TLS versions it supports, the cipher suites it supports (algorithms for key exchange + encryption + authentication), a random nonce, and crucially — a key share: the browser's public half of a Diffie-Hellman key exchange.
Step 2 — Server Hello + Key Derivation: The server responds with its chosen cipher suite, its own Diffie-Hellman key share, and a random nonce. Now both sides have what they need. Using Elliptic Curve Diffie-Hellman (ECDHE), each side independently performs a mathematical operation combining their own private key with the other side's public key share. The result — due to the mathematics of elliptic curves — is identical on both sides, even though neither private key was ever transmitted. This shared result is used to derive the session keys that will encrypt all subsequent communication.
Step 3 — Authentication: The server sends its certificate (signed by a Certificate Authority) and a Certificate Verify message — a signature of the handshake transcript, signed with the server's private key. This proves the server actually possesses the private key corresponding to the certificate's public key, and that the certificate was issued by a trusted CA.
Step 4 — Finished: Both sides send a Finished message encrypted with the new session keys. Handshake complete. All subsequent data is encrypted with AES-GCM (a symmetric cipher) using those session keys.
The mathematically elegant core: at no point was the session key or any private key transmitted. An interceptor who captured every single packet of the handshake cannot derive the session key. This is forward secrecy — even if the server's private key is later compromised, past sessions cannot be decrypted.
Why Does It Matter?
- Certificate chains are the human element — and the weak point. Your browser pre-installs ~150 root Certificate Authority certificates. When a server presents its certificate, your browser walks the chain: server cert → intermediate CA cert → root CA cert. If the chain terminates at a trusted root, the server is authenticated. This system works as long as CAs are trustworthy. In 2011, DigiNotar (a Dutch CA) was compromised and issued fraudulent Google certificates used in a MITM attack on Iranian users. The entire CA was revoked. The CA system is a trust hierarchy, and trust hierarchies have points of failure.^1
- Certificate Transparency logs are an overlooked attack surface. Since 2018, browsers require all publicly-trusted certificates to be logged to Certificate Transparency (CT) logs — public, append-only records of every certificate issued for every domain. This is great for security (you can monitor for fraudulently issued certs for your domain). It also means attackers can search CT logs for certificates issued for your internal infrastructure before you've set it up, surfacing new hostnames and subdomains. Tools like
crt.shmake this trivially easy. If you're running CT monitoring for your domains, you're ahead of most. - SNI leaks your destination even over HTTPS. The TLS handshake includes an extension called Server Name Indication (SNI) where the client tells the server which hostname it's connecting to — necessary for virtual hosting (one IP, many domains). The problem: SNI is transmitted unencrypted, before the handshake completes. Your ISP, your network admin, anyone watching the wire can see which server you're connecting to, even though they can't see the content. Encrypted Client Hello (ECH) — now being deployed in Chrome and Firefox — encrypts the SNI field using a public key published by the server in DNS. This closes the leak.^2
- Misconfiguration is still the primary TLS attack vector at the application layer. HSTS (HTTP Strict Transport Security) prevents SSL stripping attacks — without it, an attacker between you and the user can downgrade HTTPS to HTTP and intercept everything. Mixed content (HTTPS page loading HTTP resources) creates partial exposure. Wildcard certificates issued for
*.example.comcreate risks if any subdomain is compromised. Certificate expiry is embarrassingly common — in 2023, Microsoft Azure suffered a major outage partly traced to an expired certificate. Let's Encrypt + auto-renewal removes the expiry risk, but adds the risk of misconfiguring the renewal process.^3 - Post-quantum is being deployed now, not in the future. Elliptic curve cryptography — the basis of TLS key exchange — is vulnerable to quantum computers running Shor's algorithm. A sufficiently powerful quantum computer could break ECDHE and decrypt any intercepted TLS session retroactively. The attack is called harvest now, decrypt later: adversaries record encrypted traffic today, hold it, decrypt when quantum computers mature. NIST finalised post-quantum cryptographic standards in 2024 (ML-KEM/CRYSTALS-Kyber for key encapsulation, ML-DSA for digital signatures). Chrome and Firefox have already deployed hybrid post-quantum key exchange (X25519MLKEM768) in TLS handshakes. You don't need to do anything — your browser is already doing it. But if you operate infrastructure where TLS sessions are initiated by your server code, check that your TLS library supports hybrid post-quantum key exchange.
Key People & Players
Taher ElGamal — Developed the ElGamal encryption scheme that influenced SSL's key exchange design. SSL 3.0 (1996) was the protocol TLS replaced.
Whitfield Diffie & Martin Hellman — Invented public-key cryptography and the Diffie-Hellman key exchange in 1976. The mathematical foundation that makes secure key negotiation over an insecure channel possible. ECDHE in TLS 1.3 is a direct descendant of their original algorithm.
The IETF TLS Working Group — The standards body that produced TLS 1.3 (RFC 8446). The spec took 4 years and 28 draft versions to finalise. Notable contributors include Eric Rescorla (Mozilla), Ilari Liusvaara, and many others. TLS 1.3 removed a decade of technical debt from TLS 1.2.
Let's Encrypt — Non-profit CA that provides free, automated certificate issuance and renewal (ACME protocol). Before Let's Encrypt launched in 2016, deploying HTTPS required paying for certificates and manual renewal. Let's Encrypt is now the most widely used CA in the world, responsible for HTTPS becoming the default rather than the exception.^4
Cloudflare — The largest TLS termination layer on the internet. Handles a significant fraction of all TLS handshakes globally. Their learning blog has some of the clearest technical explanations of TLS concepts outside academic papers.
The Current State
TLS 1.3 is the current standard and now handles the substantial majority of HTTPS traffic. TLS 1.2 is still supported for legacy compatibility but being progressively deprecated. TLS 1.0 and 1.1 are effectively dead — browsers removed support in 2020–2022.
The active frontiers:
Post-quantum migration — Chrome and Firefox now use hybrid post-quantum key exchange by default. Server-side migration is underway. The 5–10 year window before quantum computers can break current crypto is the pressure gradient.
Encrypted Client Hello (ECH) — Standardised as RFC 9457 in 2024. Eliminates the SNI privacy leak. Cloudflare, Fastly, and major CDNs support it. Adoption growing.
Certificate Lifetime Reduction — Apple unilaterally announced that Safari will only trust certificates with a maximum lifetime of 47 days (down from 398 days), effective September 2025. This forces automated certificate management to be standard practice, not optional. Manual certificate renewal becomes effectively impossible at 47-day intervals.
ACME everywhere — The Automated Certificate Management Environment protocol (RFC 8555, the tech underlying Let's Encrypt) is being adopted by enterprise CAs. The era of manually managed certificates is ending.
The practical summary for builders: get HTTPS right (auto-renewing certs, HSTS headers, no mixed content, no old TLS versions), monitor your CT logs, and let your TLS library handle post-quantum. The heavy lifting is done for you — but understanding what's happening underneath makes you meaningfully better at debugging the gaps.
Best Resources to Learn More
- The Illustrated TLS 1.3 Connection (tls13.xargs.org) — The single best technical resource on TLS. Every byte of a real TLS handshake, annotated and explained. Extraordinary work.^5
- Cloudflare: What happens in a TLS handshake? — Clear, practical explanation at the right level of depth.^6
- High Performance Browser Networking by Ilya Grigorik (O'Reilly, free online) — Chapter 4 covers TLS in detail, including performance implications. Essential reading for anyone optimising web applications.^7
- crt.sh — Certificate Transparency log search. Search your own domain, see what certificates exist. Immediately useful.^8
- RFC 8446 (TLS 1.3) — The actual spec. The abstract and introduction are accessible. Worth reading at least the first 20 pages for historical context.^9