The general shape of MITM
"Man-in-the-middle" describes any attack where an adversary positions themselves between two communicating parties, intercepts the messages, and either eavesdrops, modifies, or impersonates one of the parties. The classic targets are:
- Your device β the website you're visiting
- Your device β your DNS resolver
- Your device β your WiFi access point
- Your device β your ISP
For the attack to be useful, the attacker either has to be positioned on a network you transit (same WiFi, same local network, controlling a hop along the path) or has to trick your device into routing traffic through them.
The specific mechanisms
ARP spoofing
On a local network, devices use ARP (Address Resolution Protocol) to map IPs to MAC addresses. ARP is trust-based β devices believe each other by default. An attacker on the same WiFi can broadcast fake ARP replies claiming "I'm the router," redirecting other devices' traffic to themselves first.
Once positioned, the attacker forwards traffic to the real router (so internet still works) but reads or modifies it in flight. Detection is tricky for end users β modern OSes are slightly suspicious of unsolicited ARP changes but generally accept them.
DNS spoofing / DNS hijacking
Two variants:
- Spoofing: an attacker on your network intercepts your DNS queries and returns false answers, sending you to attacker-controlled servers instead of the real ones. You think you're visiting bank.com but you're visiting an attacker's clone.
- Hijacking: an attacker compromises or controls the DNS resolver itself β typically by controlling a malicious WiFi AP or hacking a vulnerable home router.
DNS spoofing alone isn't sufficient to defeat HTTPS β the attacker still needs a valid certificate for the spoofed domain. But it's a prerequisite for many other attacks (especially phishing).
Rogue access point / evil twin
Covered in detail at public WiFi risks. The attacker creates a fake WiFi AP with a familiar SSID, tricks devices into connecting, and becomes the "router" for that traffic. Combines naturally with ARP and DNS attacks since the attacker controls the entire local network.
SSL stripping
HTTPS is supposed to be enforced by the website, not the attacker. SSL stripping exploits the gap: when you type "bank.com" in your browser, your initial request goes via HTTP (port 80), and the site usually responds with a redirect to HTTPS. An attacker can intercept that initial HTTP request and serve their own page over HTTP, never escalating to HTTPS.
The user sees a slightly different URL (no lock icon, no HTTPS), but most users don't notice. HSTS (HTTP Strict Transport Security) headers and the browser's HSTS preload list close this hole for major sites. For smaller sites without HSTS, the attack still works on first connections.
Fake certificates
HTTPS depends on Certificate Authorities (CAs) signing legitimate certificates for domain owners. If an attacker can obtain a valid certificate for a domain β either legitimately (through compromise) or by exploiting a buggy CA β they can MITM HTTPS connections that look completely legitimate to the browser.
Historical incidents:
- DigiNotar (2011): Dutch CA compromised; 500+ fake certificates issued for Google, Yahoo, and others. Used to MITM Iranian Gmail users.
- Symantec (2017): chronic misissuance; Google and Mozilla distrusted the CA's certificates.
- Various corporate CAs: enterprises sometimes install their own root CAs on managed devices to MITM employee traffic for security monitoring.
Certificate Transparency logs (CT) make rogue cert issuance more detectable but don't prevent it in real time.
BGP hijacking
The internet's routing protocol (BGP) lets ISPs and large networks announce which IP blocks they handle. If a malicious or compromised network announces routes for IPs it doesn't own, traffic destined for those IPs gets redirected through them. Used in real attacks against cryptocurrency services (multiple incidents 2014-2018).
End-user defenses against BGP hijacks are limited; mostly this is an internet-infrastructure problem. A VPN can help marginally by routing through a different network path.
What HTTPS protects against
HTTPS, when properly implemented and validated, prevents attackers from:
- Reading the content of your encrypted traffic.
- Modifying the content in transit.
- Impersonating the destination server (assuming the CA system isn't compromised).
HTTPS does NOT prevent:
- Metadata observation (SNI, DNS, IP).
- Traffic analysis (timing, size, pattern).
- Attacks that exploit CA compromise.
- Phishing via lookalike domains.
Where a VPN adds value
- Closes the metadata layer. ARP/DNS spoofing on the local network can't see your destinations because they're encrypted in the tunnel.
- Bypasses local network attackers. The VPN tunnel terminates at the provider's server, not at the rogue local AP. ARP/DNS attacks on the local network can't see inside the tunnel.
- Different network path. If your traffic transits a compromised BGP route, the VPN's exit point may use a different path.
- Reduces SNI exposure. Your SNI on the VPN connection is just "ClownVPN's network," not the actual destination.
A VPN does NOT prevent:
- Attacks on your endpoint device (malware, keyloggers).
- CA compromise at the application layer.
- MITM at the VPN provider itself (which is why provider trust matters).
Defensive layering
Solid defense in 2026 looks like:
- HTTPS everywhere β browser extensions or built-in browser behavior that prefers HTTPS.
- VPN on untrusted networks β public WiFi, hotel WiFi, conference WiFi, any time you don't trust the local network.
- OS and browser updates β patches close known MITM-adjacent vulnerabilities.
- Watch for cert errors β when your browser warns about a certificate, take it seriously.
- Don't use public USB ports for charging β juice jacking is the physical-layer MITM.