Networking & Protocols
What TLS does and why it exists
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.
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
- 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).
- 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.
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