TL;DR: The browser checks HSTS and its caches, resolves the name through DNS (spoofing and cache poisoning are the risks; DNSSEC, encrypted DNS and above all TLS certificate validation are the defences), opens a TCP connection (SYN floods affect availability), runs the TLS handshake (the certificate proves the server's identity for that name; forward-secret key exchange protects the session), sends an HTTP request carrying cookies (Secure, HttpOnly and SameSite matter here), and the server authenticates and authorises the request. The response is rendered under the same-origin policy with CSP limiting what scripts can run, while CORS controls which other origins may read responses. The single control that rescues most network-layer failures is certificate validation, which is why HSTS exists: to make sure the browser never skips it.
How to approach it
Walk the stack in order and keep each step short: what happens, who could attack there, which control stops them. Interviewers use this question to see breadth and ordering; they will interrupt and go deep at whichever layer you sound least sure about, so keep each claim precise.
A strong answer
Most network-layer failures are rescued by one step: certificate validation.
HSTS check
HTTPS only?
DNS
name to address
TCP
three-way handshake
TLS
certificate + keys
HTTP
request + cookies
Render
same-origin, CSP
What goes wrong, and what catches it
Spoofed or poisoned DNS
- Wrong IP returned
- Caught by TLS: the impostor has no valid certificate for the name
Validation skipped
- Click-through warnings, apps that accept any certificate
- HSTS makes errors non-bypassable
Cookie theft and CSRF
- Secure, HttpOnly and SameSite attributes
- Server-side authorisation on every request
Script injection
- Output encoding and CSP
- CORS decides which other origins may read responses
The whole journey
Six steps, each with its own attack and control.
1. Before the network. The browser parses the URL. If the user typed a bare name, it may try http:// first; an HSTS entry (from an earlier visit or the browser's preload list) forces https:// before any packet is sent, defeating SSL stripping on the first request.
2. DNS. The resolver library asks a recursive resolver (often the ISP's or a public one) which walks root, TLD and authoritative servers.
- Attacks: a malicious Wi-Fi network answering with its own resolver, cache poisoning of a recursive resolver with forged responses, hijacking the domain's registrar account or authoritative DNS.
- Defences: source port and transaction ID randomisation against forgery, DNSSEC signatures that let validating resolvers detect forged records, DNS over HTTPS or TLS for privacy and integrity on the first hop, registrar locks and MFA. Even if DNS lies, TLS certificate validation should stop the browser trusting an impostor.
3. TCP. SYN, SYN-ACK, ACK. Attacks here are mostly availability: SYN floods exhaust half-open connection state (SYN cookies and upstream DDoS protection mitigate). Off-path injection into established connections is impractical with modern sequence number randomisation.
4. TLS. The client sends ClientHello with a key share and the server name (SNI). The server answers with its key share; the rest of the handshake is encrypted. The server sends its certificate chain and a CertificateVerify signature over the handshake transcript, then Finished.
- The client validates the chain to a trusted root, checks validity dates and that the certificate's subject alternative names include the hostname, and checks the signature proves possession of the private key.
- Ephemeral Diffie-Hellman gives forward secrecy.
- Attacks: an interceptor without a trusted certificate fails validation; one with a mis-issued certificate or a user-installed root succeeds, which is what Certificate Transparency monitoring and pinning (in apps) address. A user clicking through a warning undoes everything, which HSTS also blocks.
- Metadata still visible: IP addresses, SNI (unless Encrypted Client Hello is used), timing and sizes.
5. HTTP request. Cookies for the site are attached. Secure keeps them off plain HTTP, HttpOnly keeps them from scripts, SameSite limits cross-site sending (CSRF). The server authenticates the session and must authorise the specific request; TLS says nothing about whether this user may see this resource.
6. Response and rendering. The page runs under its origin (scheme, host, port). The same-origin policy stops other origins reading it; CORS headers relax that deliberately for specific origins. Content Security Policy restricts script sources to limit XSS; frame-ancestors stops clickjacking. Subresources (scripts from CDNs) are in the trust boundary; Subresource Integrity pins their hashes.
What interviewers probe next
- "DNS returns the attacker's IP. What happens next?" The browser connects to the attacker, who cannot present a valid certificate for the name, so the TLS handshake fails, unless the user overrides the warning or the attacker holds a trusted certificate. HSTS removes the override.
- "What can someone on the same Wi-Fi still learn?" Destination IPs, SNI without ECH, DNS queries without encrypted DNS, traffic timing and volumes.
- "Where does authentication of the user happen in all this?" Not in TLS (unless mutual TLS is used); in the application, through the session cookie or token, followed by authorisation checks.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A user types bank.example into a browser on a laptop at an airport, and an interviewer asks you to walk the trip and defend it as conditions change.
Start here
What happens before any network request?
Does the browser start with HTTP or HTTPS?
The browser checks HSTS and its caches. If bank.example is on the HSTS preload list or has a stored HSTS policy, the browser goes straight to HTTPS, removing the plain HTTP first request that attackers can intercept.
Carry it forwardHSTS removes the insecure first hop.
Weak answerStarting the walkthrough at DNS.
Constraint changes
What if the airport's DNS lies?
What stops a fake server even if DNS is wrong?
DNS spoofing or a malicious resolver can return an attacker's address. Encrypted DNS and DNSSEC help, but the decisive defence is TLS certificate validation: the attacker cannot present a valid certificate for bank.example.
Carry it forwardCertificate validation defeats DNS lies.
Weak answerRelying on DNS to authenticate the server.
Constraint changes
What does the TLS handshake protect?
What can the Wi-Fi operator still see?
The certificate proves the server's identity for that name, and forward-secret key exchange protects the session, so the airport network can see only metadata and encrypted traffic.
Carry it forwardTLS authenticates the server and encrypts the session.
Weak answerThinking TLS hides the destination entirely.
Constraint changes
What if the user clicks through a certificate warning?
Can the user bypass the warning?
Then the authentication that defeats on-path attackers is gone, and the attacker can read and modify everything. HSTS makes such warnings non-bypassable for the site, which is why it matters.
Carry it forwardHSTS makes certificate errors fatal.
Weak answerAllowing users to click through.
Constraint changes
What happens after the page loads?
What threats remain once the connection is secure?
Cookies should be Secure, HttpOnly and SameSite; the page applies a content security policy; and the bank authenticates the user with strong MFA. Network protection does not cover a compromised laptop or a phishing page on another domain.
Carry it forwardSession and endpoint security finish the job.
Weak answerTreating HTTPS as the whole defence.
Now defend it
How would you summarise the defences along the trip?
HSTS preload ensures HTTPS from the first request; DNS may be spoofed, but certificate validation for bank.example defeats impersonation; TLS with forward secrecy protects the session; HSTS makes certificate errors non-bypassable; and secure cookies, CSP and strong MFA protect the session and user, while endpoint security and phishing remain separate risks.
How it's scored
Weak: "DNS gives the IP, then HTTPS encrypts everything."
Hire: Walks DNS, TCP, TLS, HTTP and rendering in order with an attack and defence at each, and identifies certificate validation as the key control.
Strong Hire: Adds HSTS before the first packet, DNSSEC versus encrypted DNS, the exact checks in certificate validation and CertificateVerify, what metadata stays visible, cookie attributes, authorisation as separate from TLS, and CSP, CORS and frame-ancestors at rendering.
Common mistakes
- Saying HTTPS makes the whole exchange invisible.
- Forgetting HSTS and the first-request downgrade.
- Treating DNSSEC as encryption.
- Confusing TLS server authentication with user authorisation.