FSD Frontend System Design

Part II β€” The Shield Β· Lesson 3.6

Secure Communication (HTTPS)

In one lineTLS gives you three things at once: encryption, integrity, and proof of who you're talking to.

Where you've seen itPublic wifi that injects a banner ad into a page β€” possible only because that page travelled as plain HTTP.

  • Time15 min
  • DiagramTLS 1.3 handshake + what each guarantee stops
  • Chapter3 Β· Security

Diagram

diagram
TLS 1.3 HANDSHAKE β€” one round trip, then encrypted

  Client                              Server
    │── ClientHello ────────────────────►│  ciphers + key share
    │◄─ ServerHello + certificate ───────│  key share + proof of identity
    β”‚   (client verifies cert chain      β”‚
    β”‚    against trusted root CAs)       β”‚
    │── Finished ───────────────────────►│
    β•žβ•β•β•β•β•β•β• application data, encrypted β•‘

  TLS 1.2 needed 2 RTT. TLS 1.3 needs 1 β€” and 0 on resumption.
diagram
THREE GUARANTEES, THREE ATTACKS STOPPED

  Encryption   ─► nobody on the path can READ it      (wifi sniffing)
  Integrity    ─► nobody can MODIFY it undetected     (ad injection)
  Identity     ─► you're talking to the real server   (impersonation)

  A padlock proves identity + encryption.
  It does NOT prove the site is honest β€” phishing sites have padlocks too.
diagram
HSTS β€” closing the first-request gap

  Without HSTS:
    user types example.com ──► http:// ──► 301 to https://
                                 └── that one request is interceptable

  With HSTS (after first visit):
    user types example.com ──► browser rewrites to https:// internally
                               no plaintext request ever leaves

  Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

How it works

  1. Client and server agree on a cipher and exchange key material in one round trip.
  2. The certificate proves the server controls the domain; the browser validates the chain to a trusted root.
  3. Session keys encrypt everything after the handshake; forward secrecy means a later key compromise can't decrypt past traffic.
  4. HSTS removes the plaintext first hop on subsequent visits; the preload list removes it even on the first.
  5. Mark cookies Secure so they never travel over HTTP at all.

Trade-offs

ConcernReality
"TLS is slow"TLS 1.3 is 1 RTT, 0 on resume; HTTP/2 and /3 require it
Mixed contentOne http:// subresource downgrades the whole page's trust
Certificate expiryThe most common self-inflicted outage β€” automate renewal
HSTS preloadEffectively permanent; be certain before submitting

Interview angle

"Site is HTTPS. Is the data safe?"

  • In transit, yes: encrypted, tamper-evident, and the server's identity is verified.
  • Not at rest, not in the browser, and not against XSS β€” TLS protects the pipe, not the endpoints.
  • Add HSTS for the first-request gap, Secure cookies, and eliminate mixed content.

Recap

  • Encryption, integrity, identity β€” three guarantees from one protocol.
  • HSTS closes the plaintext gap that a redirect alone leaves open.
  • HTTPS protects the wire; it says nothing about what either end does with the data.