MITM attacks
The HTTPS article mentioned this attack in passing while explaining what a certificate is for, promising it would be "covered in more depth later in this course." This is that article. NIST's glossary gives the formal definition: a man-in-the-middle (MITM) attack is "a form of active wiretapping attack in which the attacker intercepts and selectively modifies communicated data to masquerade as one or more of the entities involved in a communication association." The load-bearing word there is active — a MITM attacker isn't just listening, the way a passive eavesdropper on an unencrypted Wi-Fi network might. They've positioned themselves so that traffic from both sides actually passes through them, and each side believes it's talking directly to the other.
That positioning is the hard part of any MITM attack, and different techniques achieve it at different layers.
ARP spoofing: the local-network version
The ARP article already walked through this one in full: a device on the local segment sends forged ARP replies claiming to own the gateway's IP address, and because ARP has no authentication built into it at all, every other device on the segment simply starts sending its outbound traffic to the attacker's MAC address instead of the real gateway's. It's worth restating only the conclusion here, not the mechanism: ARP spoofing is a MITM attack, specifically the variant that works on a shared local network — the same office Wi-Fi, the same coffee shop hotspot, the same misconfigured VLAN — because it exploits ARP's complete lack of any way to verify a claim.
A rogue access point: the same idea, one layer up
A MITM attacker doesn't need to already be on the network at all if they can convince a victim's device to join a network they control instead. A rogue access point (sometimes called an "evil twin") broadcasts a Wi-Fi network name identical or very close to a legitimate one — Airport_Free_WiFi next to the real Airport_WiFi, or an exact clone of a coffee shop's actual network name — and a phone or laptop configured to auto-join known network names, or a user picking the wrong one from a list, connects straight to the attacker's hardware instead. From that point on, the attacker's access point is the gateway for that device: every packet the victim sends to the internet passes through hardware the attacker fully controls, with no spoofing or trickery required afterward, because the victim connected to it directly and voluntarily.
This is precisely why connecting to unfamiliar public Wi-Fi carries real risk beyond simple eavesdropping — the VPN basics article already named "an unencrypted public Wi-Fi network at a coffee shop or airport" as one of the most commonly cited reasons to use a VPN, and a rogue access point is the concrete attack that reasoning is defending against: a tunnel to a trusted VPN gateway means the local access point, rogue or not, only ever sees encrypted traffic addressed to that gateway, regardless of what else it's positioned to intercept.
DNS spoofing: redirecting by lying about the address
Where ARP spoofing lies about a MAC address and a rogue AP lies about being a whole network, DNS spoofing (also called DNS cache poisoning) lies about where a domain name actually points. The recursive DNS lookup article already explained that a DNS response is a plain UDP packet with no built-in authentication of its own — a resolver has no cryptographic way to confirm a given response actually came from the authoritative server it queried, only that the packet's transaction ID and source port appear to match what it expected. An attacker positioned to intercept or race that response — on the local network via the same ARP spoofing already covered, or by racing a legitimate response with a forged one guessing the right transaction ID — can substitute their own answer: a query for bank.example.com receives a spoofed A record pointing at a server the attacker controls, and every subsequent connection to that hostname goes straight to the attacker's infrastructure instead, with nothing about the DNS lookup itself looking unusual to the victim's device.
DNSSEC — a set of DNS extensions that cryptographically sign records so a resolver can verify a response actually came from the domain's real authoritative server — exists specifically to close this gap, though deploying it fully across the DNS hierarchy is a separate, larger topic than this article covers.
Why TLS defeats most of this — and the one place it doesn't
Every technique above achieves the same thing: getting attacker-controlled hardware into the path between a victim and whatever they meant to reach. What happens next depends entirely on whether the connection riding on top of that path is encrypted and authenticated.
If the victim then connects to a plain http:// site, the attacker sitting in the path reads and can rewrite every byte, because there's nothing protecting it. If the victim connects to https://, the TLS handshake is specifically designed to defeat exactly this scenario: the server presents a certificate, and the client verifies that certificate's signature traces back to a certificate authority it already trusts, as the HTTPS and PKI article covered in depth. An attacker in the middle of the connection can forward traffic, but cannot produce a valid certificate for a domain they don't control — no ARP trick or rogue access point grants them a CA's private signing key. The connection either fails outright with a certificate warning, or the attacker is forced to terminate TLS themselves and hope the victim ignores the resulting warning, which is a much louder failure than silent interception.
HTTPS doesn't prevent an attacker from getting into the path — it prevents them from impersonating the destination once they're there. That's the entire reason certificate warnings exist as hard failures rather than dismissible notices in a modern browser.
There is one historical technique worth naming because it exploited a gap in how this protection used to be applied rather than in TLS itself: SSL stripping. Before browsers consistently enforced HTTPS by default, a MITM attacker could intercept a victim's initial plain HTTP request — the one a browser sends before ever attempting HTTPS, for a site typed in without https:// — and silently proxy the rest of the session over HTTP to the victim while connecting to the real site over HTTPS itself, downgrading the connection the victim never got a chance to upgrade in the first place. HSTS (HTTP Strict Transport Security), a response header telling the browser to refuse plain HTTP for a domain entirely for a specified period, closes this specific gap by removing the vulnerable first plaintext request from the picture on every visit after the first.
Practical scenario: a certificate warning nobody should have ignored
A user on a hotel's guest Wi-Fi reports that their banking site "looks broken" — the page loads, but the browser shows a full-page certificate warning instead of the login form.
Your connection is not private
Attackers might be trying to steal your information from bank.example.com
NET::ERR_CERT_AUTHORITY_INVALID
Checking the certificate the browser actually received, rather than guessing, is the right first step:
echo | openssl s_client -connect bank.example.com:443 -servername bank.example.com 2>/dev/null | openssl x509 -noout -issuer -subject
The subject correctly claims to be bank.example.com, but the issuer is Hotel-Guest-Portal-CA — not a certificate authority any browser trusts by default, and not one that has any business signing a certificate for a domain the hotel doesn't own. This is a hotel guest network intercepting HTTPS traffic and re-signing it with its own certificate, typically as a byproduct of a captive-portal or "traffic inspection" appliance the hotel's network deliberately runs — functionally a MITM position, regardless of the hotel's actual intent, and indistinguishable from a malicious one from the browser's point of view. The browser's warning is not a false alarm to click through; it's the certificate check from the HTTPS article working exactly as designed, refusing to proceed because the entity in the middle cannot produce a certificate signed by a CA the browser actually trusts.
Never dismiss a certificate warning to get past it, especially on an unfamiliar network
A certificate warning means the browser could not verify it's actually talking to the domain it intended to reach — not a formality, not a compatibility glitch. The correct response is to stop, not retry the same site with the warning dismissed, and not enter any credentials until connecting from a network you trust, or through a VPN tunnel that removes the untrusted network from the path entirely.
Practice exercises
- A colleague argues that connecting to a coffee shop's Wi-Fi is safe as long as every site they visit uses HTTPS. Using the rogue access point and SSL stripping sections above, identify the one gap in that reasoning and the browser feature that closes it.
- Explain why DNS spoofing and ARP spoofing both count as MITM techniques even though one operates on IP-to-domain mappings and the other on IP-to-MAC mappings — what property do they share that makes both effective?
- A security audit finds that a company's internal network still resolves DNS without DNSSEC validation anywhere in the chain. Explain, in concrete terms, what specific attack from this article that gap leaves the network exposed to, and why DNSSEC would close it.
Every technique in this article gets easier the moment an attacker controls, or can pose as, the network in between — a Wi-Fi access point, a local segment, an ISP. The most direct defense against exactly that threat model is refusing to trust the network in between at all, and encrypting the entire path to a gateway you do trust before any of this traffic is exposed to it. That's the next article's subject.