What Happens When You Type https://example.com

#What is this?

When you press Enter on https://example.com, the browser has to answer four questions in order: where is it? (DNS turns the name into an IP address), how do I reach it? (a TCP or QUIC connection across the internet), is it really them, and can anyone listen in? (TLS proves the server's identity with a certificate and agrees encryption keys), and what do they want me to show? (an HTTP request, then parsing and rendering the response).

Interviewers ask this because there is no bottom to it. A junior answer names the four steps. A senior answer explains what is cached where, what each step costs in round trips, what an attacker could do at each hop, and which control stops them.

#Why it matters

Memory hook

"Where, How, Who, What"Where is it (DNS) → How do I get there (TCP/QUIC) → Who am I talking to, privately (TLS + certificate) → What do I show (HTTP + rendering). Hang every detail off one of those four hooks and you'll never lose your place mid-answer.

#Step 1 — The browser parses what you typed

Before any packet leaves the machine, the browser does a surprising amount of local work.

Tip

Typing example.com without a scheme is a better interview variant: then you get to explain HTTPS-First / "Always use secure connections" mode and HSTS preload. Without them, the first request goes out as plaintext http:// and an on-path attacker can "SSL-strip" it.

#Step 2 — DNS: turning the name into an address

#The cache cascade

Each layer only asks the next one if it doesn't already have a fresh answer (one whose TTL — time to live — hasn't expired).

#What goes on the wire

;; QUESTION — client → recursive resolver (UDP 53, random source port, random 16-bit ID)
example.com.            IN  A        ; EDNS0, DO bit set = "send me DNSSEC records"

;; ANSWER — recursive resolver → client
example.com.     300    IN  A        192.0.2.10      ; documentation address (RFC 5737), illustrative
example.com.     300    IN  RRSIG    A 13 2 300 ( ... signature by example.com's ZSK ... )
;; flags: qr rd ra ad      ← "ad" = Authenticated Data: the resolver validated DNSSEC

The recursive resolver walks the hierarchy one referral at a time. With QNAME minimisation (RFC 9156) it only tells the root "who runs .com?" rather than leaking the full name to every server.

#Step 2b — DNSSEC: proving the answer wasn't forged

What it isDNS Security Extensions (DNSSEC) add signatures to DNS records so a resolver can prove an answer really came from the zone owner and wasn't changed on the way. It gives authenticity and integrity, not confidentiality: the query and answer are still readable.

How the chain of trust worksEach zone signs its own records, and the parent zone vouches for the child's key. Validation walks up until it reaches the one key everyone has pre-installed: the root key.

Important

Browsers do not validate DNSSEC themselvesValidation happens at the recursive resolver, and the browser trusts the AD bit. So the last hop (laptop → resolver) is only protected if it is encrypted (DoH/DoT) or local. DNSSEC is also not what stops a spoofed IP from becoming a working MITM: TLS certificate validation does that. A forged DNS answer sends you to the wrong server, but that server can't present a valid certificate for example.com.

Full detail on key rollovers, NSEC3 zone walking and DNSSEC's downsides: DNS Deep Dive → DNSSEC.

#Step 3 — Reaching the server: routing, Happy Eyeballs, TCP or QUIC

With HTTP/3 the TCP and TLS round trips merge into one, and with TLS 1.3 0-RTT resumption a returning visitor can send the GET in the very first flight.

#Step 4 — The TLS 1.3 handshake

The goal: agree on fresh encryption keys that only the two endpoints know, and prove the server is the real example.com, in a single round trip.

sequenceDiagram
  autonumber
  participant B as Browser
  participant S as example.com (CDN edge)
  B->>S: ClientHello<br/>SNI example.com · ALPN h2<br/>key_share X25519MLKEM768 · sig algs
  Note over B,S: Plaintext so far (except ECH inner hello)
  S->>B: ServerHello<br/>TLS_AES_128_GCM_SHA256 · key_share
  Note over B,S: Both derive handshake keys (ECDHE + HKDF)<br/>everything below is encrypted
  S->>B: EncryptedExtensions (ALPN h2)
  S->>B: Certificate<br/>leaf + intermediate, SCTs
  S->>B: CertificateVerify<br/>signature over transcript
  S->>B: Finished (MAC over transcript)
  Note over B: Validate cert chain,<br/>signature, Finished
  B->>S: Finished
  B->>S: HTTP/2 SETTINGS + GET /
  S-->>B: NewSessionTicket (resumption)

Why each server message matters:

Byte-level detail, the key schedule, PSK resumption and 0-RTT are in the TLS in depth section.

#Step 5 — How the browser validates the certificate

This is the step that actually defeats a man-in-the-middle (MITM) attacker. A DNS spoof or a BGP hijack can send you to the wrong server, but that server can't produce a certificate for example.com signed by a CA the browser trusts — plus a CertificateVerify signature made with the matching private key.

flowchart TB
  L["Leaf<br/>CN/SAN: example.com<br/>CA:FALSE · EKU serverAuth<br/>valid ≤ 200 days"] -->|"signed by"| I["Intermediate CA<br/>CA:TRUE, pathLen 0"]
  I -->|"signed by"| R["Root CA<br/>self-signed<br/>in the browser's root store"]
  R -.->|"trusted because it's<br/>pre-installed"| T["Chrome Root Store /<br/>Mozilla NSS / Apple"]

Warning

Corporate TLS inspection breaks this model on purpose. A proxy presents its own certificate for example.com, signed by a corporate root that IT pushed into the OS trust store. The browser accepts it because the root is "trusted". This is why endpoint trust stores are crown jewels, and why attackers who install a root CA (malware, a rogue MDM profile) get silent MITM.

#Step 6 — The HTTP request and the server side

Inside the encrypted tunnel, HTTP/2 sends binary frames. Decoded, the first request looks like this:

:method: GET
:scheme: https
:authority: example.com
:path: /
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 ... Chrome/1xx
accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
accept-encoding: gzip, deflate, br, zstd
accept-language: en-GB,en;q=0.9
sec-fetch-site: none          ← typed by the user: not triggered by another site
sec-fetch-mode: navigate
sec-fetch-dest: document
sec-fetch-user: ?1
upgrade-insecure-requests: 1
priority: u=0, i

No cookies are sent on a first visit. On later visits, cookies for example.com ride along unless their SameSite, Secure or Path rules exclude them.

#Step 7 — The browser applies policy, then renders

#Security angle — attacks and controls at every hop

Memory hook

"DNS points, TLS proves." DNS (even with DNSSEC) only tells you where to go. TLS certificate validation is what proves you arrived at the right place. When asked "what if DNS is poisoned?", the answer is: you connect to the wrong IP, and the attacker fails at the certificate step, unless they also have a trusted certificate for the name.

#How to deliver the answer

Tip

Draw it while you talk: four boxes (DNS · TCP · TLS · HTTP) with arrows, and put a red "attack" and a green "control" label under each one. Interviewers remember a candidate who structures the answer visually.