On public coffee-shop Wi-Fi, a user sees a browser warning that the bank's certificate was issued by an unknown authority, clicks through, and later finds the account drained. The attacker was on the same wireless network and relayed the session to the real bank. Which attack occurred, and which control would have stopped it had the user heeded it?
Select an answer to reveal the explanation.
Short Explanation
It's like a fake mail carrier who opens your letters, reads them, and reseals them before passing them on. That's a man-in-the-middle, and the browser warning was your seatbelt — the forged certificate couldn't chain to a CA you trust. Clicking through the warning is the trap that undoes the whole protection.
Full Explanation
In a man-in-the-middle attack the adversary positions itself between client and server, often on shared Wi-Fi through ARP spoofing, a rogue access point, or DNS manipulation, and relays traffic in both directions while reading or altering it. To intercept HTTPS, the attacker must present its own certificate for the bank's hostname. Certificate validation exists for exactly this: the browser checks that the certificate chains to a trusted root, matches the hostname, and is within its validity period. An unknown-issuer warning is the detection, and accepting it hands the attacker the session. Session replay resends previously captured traffic later; TLS already defeats naive replay with sequence numbers and fresh keys, and the scenario describes live relay rather than delayed resending. Credential stuffing tries leaked username and password pairs at scale against a login page; it needs no position on the victim's network and produces no certificate warning. Cross-site scripting injects script into a vulnerable site's pages and does not involve a forged certificate. Exam caveat: HSTS removes the option to click through for sites that publish it. Operational check: train users never to bypass certificate warnings and confirm critical sites send HSTS headers.