Skip to content

04. TLS and HTTPS — sealing the letter and trusting the sender

~15 min read. Privacy on the internet begins with identity plus shared keys.

Built on the ELI5 in 00-eli5.md. The sealed envelope — readable only by intended parties — lets packets cross the network safely.

1) HTTPS means HTTP carried inside TLS

HTTP alone is plain text. Anyone on the path could read or modify it. TLS adds confidentiality, integrity, and authenticated identity. Confidentiality means outsiders cannot read the contents. Integrity means outsiders cannot alter bytes silently. Authentication means the browser knows which server it reached. The post office can still forward the packet. But the sealed envelope hides the letter inside. A simple layer picture helps. ┌────────────────────────────────────────────┐ │ IP │ TCP │ TLS records │ HTTP headers/body │ └────────────────────────────────────────────┘ Routers need outer addressing information only. Browsers and servers use TLS keys for the inside.

2) The TLS handshake builds trust and shared secrets

Modern web traffic usually uses TLS 1.3. The handshake tries to reduce round trips while staying secure. A simplified sequence is enough for system design interviews. ClientHello: supported TLS versions, cipher suites, random bytes, key share. ServerHello: chosen parameters and server key share. Certificate: server proves its identity for the hostname. CertificateVerify: server signs handshake data. Finished: both sides confirm derived keys work. Then encrypted application data begins. Concrete timing example helps memory. Assume RTT is 24 ms. ClientHello reaches server in 12 ms. ServerHello, certificate, and Finished return in 12 ms. Browser spends 6 ms verifying the certificate chain. Client Finished reaches server in another 12 ms. So fresh TLS setup may cost about 30 ms beyond pure TCP. A handshake sketch keeps the order clear. ┌──────────┐ ┌──────────┐ │ Browser │ │ Server │ └────┬─────┘ └────┬─────┘ │ ClientHello + key share │ ├──────────────────────────────────────────▶│ │ │ │ ServerHello + cert + Finished │ │◀──────────────────────────────────────────┤ │ │ │ Finished │ ├──────────────────────────────────────────▶│ ▼ ▼ keys ready keys ready

3) Certificates and certificate authorities create trust chains

A certificate binds a public key to a hostname. Example hostname: pay.example.com. The certificate says, "This public key represents that name." But why should the browser believe that claim? Because a certificate authority, or CA, signed it. Browsers ship with a trusted CA store. If a trusted CA signed an intermediate CA certificate, and that intermediate signed the server certificate, the browser can build a chain of trust. It also checks dates and hostname match. Worked example keeps this concrete. Leaf certificate: pay.example.com, valid until 2026-03-31. Intermediate: Example Issuing CA 7. Root: Trusted Web Root A. If any certificate is expired, validation fails. If hostname is api.example.com, validation fails. If the signature chain breaks, validation fails. That is why missing intermediates cause scary browser warnings. Hostname matching usually uses SAN, not old common-name fields. If SAN lacks the exact requested name, validation fails. Wildcard certificates help, but only within one label depth. *.example.com matches api.example.com. It does not match deep.api.example.com. That detail matters during subdomain-heavy platform growth. A certificate can be valid and still wrong for the requested host. So certificate inspection must include names, not only dates. Internal APIs using many subdomains often need SAN planning early. Otherwise certificate rotation becomes operational pain.

4) How encryption works at a high level

Public key cryptography helps start the relationship. Symmetric encryption carries the actual bulk data efficiently. A practical mental model works well. The server shows a public lock that anyone can close. Only the server holds the private key that can open certain proofs. During handshake, both sides contribute random values and key shares. From that, they derive the same session keys independently. Those session keys encrypt application records efficiently. So the heavy public-key work happens mostly during setup. The fast symmetric work handles ongoing traffic. Example with numbers helps intuition. Handshake CPU might take a few milliseconds. Streaming 1 MB with symmetric encryption is much cheaper per byte. That is why reused TLS sessions save both latency and CPU. Integrity matters too. Each TLS record includes authentication data. If an attacker flips one bit, verification fails. The browser discards tampered data instead of rendering lies. Session resumption improves repeat visits noticeably. The client remembers earlier session information. Later handshakes can skip some expensive setup work. That reduces CPU and latency for busy sites. 0-RTT data exists in some resumed paths, with caveats. Replay-sensitive requests should treat that carefully. So performance tuning and security policy meet inside TLS design. Fintech and identity systems care deeply about that tradeoff. Browsers and CDNs both benefit from resumption at scale. Saved handshakes mean saved battery on mobile devices.

5) Pinning, mTLS, and operational failure modes

Certificate pinning means trusting a narrower identity set. An app may remember one expected public key or CA. If another valid-looking certificate appears, the app rejects it. Pinning reduces some mis-issuance risk. But bad pin management can brick your clients during rotation. That is why browser-level pinning became rare on the public web. mTLS means mutual TLS. The server shows a certificate to the client. The client also shows a certificate to the server. This is common inside service-to-service platforms. Example: payments API gateway trusts only certificates from internal services. That removes the need for only password-like shared secrets. Operational failures are worth naming explicitly. Expired certificate: users see immediate TLS errors. Wrong hostname on certificate: connection rejected. Clock drift on client device: valid certificate appears expired. Missing intermediate certificate: some clients fail, others succeed. TLS version mismatch: old client cannot connect to hardened server. So HTTPS reliability is partly a cryptography problem, and partly a certificate operations problem. The address still matters, but trust binds name to key. Termination points also matter operationally. A load balancer may end TLS at the edge. Then it forwards plain HTTP or re-encrypted traffic inward. Re-encrypting to the origin protects east-west traffic too. Plain HTTP behind the edge is simpler, but weaker. Service meshes often choose mTLS everywhere instead. That keeps private traffic protected inside the data center. So "HTTPS enabled" still needs architecture detail in interviews. Auditors often ask exactly where decryption happens. Engineers should answer with diagrams, not assumptions.

Where this lives in the wild

  1. Stripe security engineer manages certificate rotation and mTLS for internal services. Trust between services matters as much as user-facing encryption.
  2. Google Chrome security engineer validates certificate chains and warns on failures. Browser trust decisions directly affect billions of daily sessions.
  3. WhatsApp infrastructure engineer depends on TLS to protect message transport metadata and content. Even intermediaries should not read private user traffic.
  4. AWS load balancer engineer terminates TLS at edge services for many customers. Efficient handshakes save massive CPU and latency budgets.
  5. Zerodha platform engineer watches certificate expiry on trading and login domains. One expired certificate can block all market-hour access.

Pause and recall

  1. What three security properties does TLS add to plain HTTP?
  2. Why does the browser trust a server certificate at all?
  3. Why are session keys used after the handshake, not public-key crypto alone?
  4. Where is mTLS more common, public browsers or internal service meshes?

Interview Q&A

Q1. Explain TLS handshake without drowning in mathematics. Say both sides negotiate parameters, verify identity, and derive shared session keys. Then encrypted HTTP can flow over the established TCP connection. Common wrong answer to avoid: "TLS just base64-encodes the request." Q2. What does a certificate actually prove? It binds a public key to a hostname, signed by a trusted CA. The browser still checks hostname, dates, and chain validity. Common wrong answer to avoid: "Certificate only proves the server owns the IP address." Q3. Why use mTLS inside backend systems? It authenticates both client and server strongly. That is useful when services, not humans, call each other. Common wrong answer to avoid: "mTLS is only for public websites with browsers." Q4. What risks come with certificate pinning? It narrows trust, but rotations and recovery become harder. A stale pin can block healthy connections completely. Common wrong answer to avoid: "Pinning is always safer and has no tradeoffs."

Apply now (5 min)

Open any HTTPS site and inspect its certificate in the browser. Write the hostname, issuer, and expiry date. Ask what would happen if the hostname mismatched the URL. Ask what would happen if your laptop clock moved one year ahead. Now explain why the site can still use fast symmetric encryption afterward. One quick mental checklist prevents many TLS mistakes. Check hostname. Check expiry. Check issuer chain. Check system clock. Check whether the proxy, CDN, or origin owns termination. Then decide whether the problem is trust, time, or routing. Write those five checks beside every incident ticket. Most certificate bugs become smaller immediately. That discipline prevents vague "SSL issue" debugging. Sketch from memory Draw TCP outside, TLS in the middle, and HTTP inside. Draw the three handshake message groups. Label certificate check, key derivation, and encrypted data start.

Bridge. Once transport is reliable and encrypted, application behavior becomes the next bottleneck. Different HTTP versions package requests very differently for performance. → 05-http-versions.md