Before two devices on the same local network can exchange a single packet, they have to solve a translation problem. The internet layer speaks in IP addresses; the wire underneath speaks in MAC addresses, the hardware identifiers burned into each network interface. Something has to map one to the other. That something is the Address Resolution Protocol — ARP — and its design is the root of the whole attack.
How ARP Is Supposed to Work
When your laptop wants to reach the router at, say, 192.168.1.1, it doesn't yet know the router's MAC address. So it broadcasts an ARP request to every device on the local segment: "Who has 192.168.1.1? Tell me your MAC address." The router replies, "That's me, my MAC is aa:bb:cc:dd:ee:ff," and your laptop caches that mapping in its ARP table so it doesn't have to ask again.
That exchange is fast, invisible, and constant. It's also completely unauthenticated. ARP has no mechanism to verify that a reply is truthful, and most implementations will happily accept an ARP reply they never asked for — a so-called gratuitous ARP — and overwrite whatever was in the cache. There is no signature, no challenge, no sender verification of any kind.
ARP trusts any answer to a question it broadcast, and many systems trust answers to questions they never asked. The protocol has no way to tell a real reply from a forged one.
Turning That Trust Into a Wiretap
ARP spoofing (also called ARP poisoning) exploits that gullibility directly. An attacker on the same local network sends forged ARP replies to two victims at once:
- To your laptop: "The router's IP belongs to my MAC address."
- To the router: "Your laptop's IP belongs to my MAC address."
Now both sides have a poisoned ARP cache. Your traffic bound for the router goes to the attacker; the router's traffic bound for you goes to the attacker. The attacker quietly forwards everything along so the connection keeps working and nothing looks wrong — and in doing so sits squarely in the middle of every packet you send. This is a textbook machine-in-the-middle position, achieved without touching the router, cracking a password, or installing anything on your device.
From that seat, a number of follow-on attacks open up: passively sniffing traffic, attempting to downgrade or strip TLS connections, injecting content, or simply dropping packets to deny service. Off-the-shelf tools have automated the whole sequence for years, which is why ARP spoofing shows up constantly in penetration tests and security training.
The One Big Limit: It's Local Only
ARP is a link-layer protocol, and its messages don't cross routers. That hands you the single most important fact about this threat: an ARP spoofing attacker has to already be on your local network segment. Someone across the internet cannot poison your ARP cache. The realistic threat scenarios are therefore shared networks — public Wi-Fi at a café, an airport, a hotel, a conference, or a corporate LAN where one machine has been compromised and is now attacking its neighbors.
That makes ARP spoofing a close relative of the evil twin attack, but the mechanism is different. An evil twin tricks you into associating with a rogue access point; ARP spoofing leaves you on the legitimate network but hijacks the local address mapping once you're there. Both end with the attacker in the middle; they just take different roads to get there.
Why HTTPS Changed the Stakes
Here's the reassuring part. Being in the middle of the network is not the same as being able to read what flows through it. When you load a site over HTTPS, the traffic is encrypted end to end and authenticated with a certificate. An ARP-spoofing attacker relaying your packets sees ciphertext, not your passwords or messages, and cannot forge a valid certificate for the site you're visiting. If they try to strip HTTPS down to plain HTTP, modern browsers and HSTS protections turn that into a visible failure rather than a silent compromise.
A certificate warning during an attempted machine-in-the-middle attack is not an annoyance to click through — it is the defense doing exactly its job. Treat it as a hard stop.
This is the practical reason end-to-end encryption matters so much on untrusted networks: it makes the attacker's position on the wire nearly worthless. What they can intercept, they can't read.
Defenses, From the Wire Up
| Layer | Defense |
|---|---|
| Network (managed) | Dynamic ARP Inspection with DHCP snooping on managed switches drops forged ARP replies before they spread. |
| Host | Static ARP entries for critical hosts; ARP-monitoring tools that alert when a MAC-to-IP mapping suddenly changes. |
| Transport | HTTPS everywhere and a VPN, so intercepted traffic is encrypted and the local network is just a dumb pipe. |
| Application | End-to-end encryption, which keeps content unreadable regardless of who controls the path. |
For most people, the actionable layers are the bottom two. You won't reconfigure a café's switch, but you can route through a VPN on untrusted Wi-Fi and refuse to bypass certificate warnings. For network administrators, Dynamic ARP Inspection is the real structural fix — it validates ARP packets against a trusted database and discards the forgeries at the switch.
Where Haven Fits
Haven assumes the network is hostile, because on public Wi-Fi it often is. Messages and email are end-to-end encrypted with keys derived on your own device, so an attacker who wins the machine-in-the-middle race through ARP spoofing intercepts only ciphertext. The wire being compromised doesn't compromise the conversation.
That's the durable lesson of a forty-year-old attack that still works: you usually can't fix the network you're borrowing, so the resilient move is to stop trusting it. Encrypt end to end, and the question of who controls the local address table stops being your problem.