What TLS does and why it exists
TLS builds a sealed channel over an untrusted network — before TLS 1.3 that took two round-trips; understanding why sets up everything that follows.
TCP agreed on sequence numbers, DNS resolved a name to an IP. Now the browser and server must agree on encryption before anything that matters can travel. That negotiation is the TLS handshake — and it is the difference between a clear-text postcard and a sealed envelope. By the end of this lesson you will know what three things TLS guarantees, why the padlock does not mean the site is safe, and why TLS 1.3 needs only one round-trip.
What TLS does in one sentence
TLS (Transport Layer Security) wraps every byte of application data in a symmetric-key envelope that nobody on the network can read. The envelope is negotiated via asymmetric cryptography during the handshake; once negotiated, the symmetric key handles all data at line speed.
Plain HTTP sends every word you type in clear text. Your password, your bank balance, the article you are reading — visible to anyone on the same coffee-shop wifi, your ISP, or a corporate proxy. TLS turns that same wire into a locked tunnel.
The sealed-envelope metaphor
Bea wants to mail Sven a message, but she fears the mailman will read it. She puts it in a box, locks it with a seal, and mails it. Only Sven has a matching key. Before mailing, both agree on the seal and the key: Bea proposes locks she knows, Sven picks one and sends his half of the key plus an ID card from Cara the trusted issuer. They combine halves into a shared seal. TLS 1.3 made the meeting shorter by letting Bea send her half in the first message, instead of waiting for Sven to ask.
Three guarantees TLS provides
Why does this matter in practice? Because breaking any one of these three opens a different class of attack — eavesdropping, tampering, or impersonation. Understanding which guarantee covers which attack lets you reason clearly about what TLS can and cannot fix.
- Confidentiality — nobody on the wire can read the data.
- Integrity — nobody can tamper with the data without detection.
- Authentication — the server proves it owns the domain (via a certificate issued by a trusted CA).
Together these three mean: your data reaches the right server unchanged and unreadable to anyone in between. Remove authentication and you might encrypt traffic to an impostor; remove integrity and a middlebox could flip bits undetected.
- TLS 1.2 cold handshake
- 2 RTT
- TLS 1.3 cold handshake
- 1 RTT
- TLS 1.3 resumed (PSK)
- 1 RTT (no cert check)
- TLS 1.3 0-RTT
- 0 RTT for request
- HTTPS share of web traffic (2025)
- ≥95%
- Browser shows padlock when
- TLS handshake succeeded
One scenario end to end
You type https://. The browser has already finished DNS (it knows the IP) and TCP (a connection is open). Now it builds the TLS seal. Once built, every HTTP request and response rides inside it. The browser shows a padlock.
The padlock means: nobody on the network can read what passes between you and this hostname. It does not mean the website is trustworthy — a scam site can have a valid padlock. It does not mean your device is safe. It guarantees only the channel.
What does TLS actually protect?
The padlock icon in the browser means...
Put the TLS handshake steps in order (simplified):
- 1 Bea sends her list of supported ciphers and her half of the key
- 2 Sven picks a cipher, sends his half of the key and his certificate
- 3 Bea checks the certificate against trusted CAs
- 4 Both sides combine their halves into a shared secret
- 5 Every message after this point is encrypted
Fill in the blank: TLS turns your connection into a sealed _______ that only the website can open.
▸Why this works
Why TLS 1.3 cut the handshake to one RTT. TLS 1.2 needed two round-trips: one to agree on cipher parameters, then another to exchange key material. TLS 1.3 moved the client’s key material into the very first message — the ClientHello — so the server can compute the shared secret and start encrypting in the same pass. This saves a full network round-trip (80–300 ms on intercontinental links) on every cold connection.
- 01In one sentence: what would happen if you visited a banking site without TLS?
- 02What three guarantees does TLS provide, and which one does the certificate serve?
- 03Why did TLS 1.2 need two RTTs and TLS 1.3 needs only one?
TLS wraps every byte of application data in an encrypted envelope that anyone on the network can see passing but only the sender and receiver can read. It provides three guarantees: confidentiality (encryption), integrity (MAC/transcript hash), and authentication (the server certificate proves domain ownership to a trusted CA). Before TLS 1.3, building this channel cost two network round-trips; TLS 1.3 collapsed it to one by sending the client’s key material in the opening message. The padlock icon means only the channel is sealed — not that the website itself is safe or the device is secure. Now when you see a padlock, you will know exactly which threat it stops — eavesdropping on the wire — and what it leaves unguarded, so you can decide what additional protection the situation calls for.
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
appears again in47
- Federation and lookahead: batching beyond DataLoadermiddle
- Senior GraphQL API: scheduling contract, tenant isolation, observabilitysenior
- Invalidation, dirty bits, and containmiddle
- Compositor layers: promotion, overlap, and GPU memorymiddle
- Production observability: LoAF, INP, and the full attack surfacesenior
- Hidden classes, transition trees, and memory layoutmiddle
- V8 in production: isolates, pointer compression, and real failuressenior
- What workers are and why they existjunior
- Web worker mechanics: dedicated, shared, and OffscreenCanvasmiddle
- Structured clone and transferablesmiddle
- SharedArrayBuffer, Atomics, and cross-origin isolationsenior
- Worker pools, Comlink, and production observabilitysenior
- Eight layers traced: from the service worker to the second navigationmiddle
- Five canonical breaks: where production reliably diessenior
- The three-track method: reading traces and building a monitored systemsenior
- Lock and single-flight: bounding concurrent rebuildsmiddle
- Stale-while-revalidate and CDN request coalescingmiddle
- Detecting stampedes and designing TTL for productionmiddle
- Metastable failure, fencing tokens, and production postmortemssenior
- What a relation is: tables, rows, keys, and constraintsjunior
- Constraints, keys, and Postgres data typesmiddle
- JSONB, arrays, and when a side table winsmiddle
- Schema integrity: deferral, versioning, and production failure modessenior
- Where data fetching happens — and why it decides LCPjunior
- React Server Components and Suspense streamingmiddle
- Senior internals: RSC payload, caching layers, and production failure modessenior
- What is OpenTelemetry: API, SDK, Collector, OTLPjunior
- OTel signals, Semantic Conventions, and the OTLP wire formatmiddle
- The OTel Collector: receivers, processors, exporters, and deployment patternsmiddle
- Vendor neutrality, eBPF instrumentation, the Operator, and browser/serverless OTelsenior
- Operating the OTel Collector: reliability, version skew, failure modes, and governancesenior
- What is trace propagation and why broken propagation is worse than nonejunior
- traceparent and tracestate: the W3C header format in fullmiddle
- Baggage and async boundaries: carrying context across queues and callbacksmiddle
- Async context per language, service mesh, B3 migration, and securitysenior
- Production propagation failures, span links, and platform designsenior
- The debugging funnel: SLO → RED → trace → profilejunior
- OTel architecture: one SDK, four signals, one wire formatmiddle
- The incident loop: from pager to postmortem to preventionmiddle
- Scale, security, and the ROI of observable systemssenior
- At-most-once, at-least-once, exactly-once: the three delivery contractsjunior
- Consumer-side dedup: the cheapest path to exactly-once processingmiddle
- Exactly-once in production: impossibility proof, hybrid patterns, and real incidentssenior
- What OAuth is and why passwords are not the answerjunior
- Authorization code flow with PKCEmiddle
- Sender-constrained tokens: DPoP and mTLSsenior
- OAuth in production: audience attacks, observability, and real failuressenior
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.