Field Notes · Technical Reality

Padlocks are Suggestions

Man-in-the-middle on a LAN: ARP spoofing to sit in the traffic, a rogue certificate to read the TLS, and the browser warning the victim trained himself to ignore.

Man-in-the-Middle (ARP spoofing + TLS interception)  ·  appears in the lecture-hall scene

Picture a small office with an internal mail system. You want to read someone’s letters, so you walk up to the mail clerk and say, quietly, “I’m the front desk now, give their outgoing mail to me.” Then you walk up to the front desk and say, “I’m that person’s office, send their incoming mail through me.” Nobody asked either of you for ID. Neither has any way to check. So the mail flows through your hands, and you read it on its way past, and everyone keeps working.

That is ARP spoofing. It is not clever. It works because the network was never designed to ask are you sure?

Two addresses, one lie

Every device on a LAN has two addresses. The IP address is logical, the one you configure, the one that gets routed. The MAC address is physical, burned into the network hardware. To actually deliver a packet on the local segment, a machine needs to map the IP it wants to reach onto a MAC address, and it does that with the Address Resolution Protocol: it broadcasts “who has 10.2.2.1?” and caches whatever answer comes back. It was designed and released in its RFC (Request for Comments) release by the IETF in 1982 as a solution to address routing in DEC, Intel, and Xerox systems by a handful of capable researchers at MIT in Cambridge, Massachusetts. This was at a time when networks were dominantly run on extremely dumb network switch hubs that were incapable of routing traffic exclusively to their intended recipients. Instead, the hubs would receive a stream of packets, then echo those same packets across all other ports to the rest of the network. Like someone being whispered to in a crowd, then promptly screaming the secret they were just told. We needed a better way. ARP was better. Marginally.

Here is the entire flaw: ARP has no authentication. A reply doesn’t have to be solicited, and nothing verifies that the sender actually owns the IP it’s claiming. A host will happily overwrite its ARP cache with an unsolicited reply. So you send a stream of forged replies (bettercap does this on a timer) telling the victim “the gateway (10.2.2.1) is at my MAC,” and telling the gateway “the victim (10.2.2.209) is at my MAC.” Both caches poison. Both machines now send through you. You enable IP forwarding so traffic still reaches its destination, and neither end notices the detour.

Becoming the middle

In the book, Cade is on the WAIT campus LAN (10.2.2.0/24, gateway 10.2.2.1) from the back row. He is seen running a very popular, open-source tool known as bettercap, which you can download from GitHub if you are so inclined. (Yes, hacking tools are free and very easy to get. Go figure.) He runs net.probe to light up the segment, and bettercap resolves each MAC’s vendor prefix (OUI) automatically, which is how he picks the target out of the noise. One endpoint on the faculty segment comes back as Apple hardware at the podium’s port.

10.2.2.0/24 > 10.2.2.203 » net.probe on
10.2.2.0/24 > 10.2.2.203 » [endpoint.new] endpoint 10.2.2.1   detected as d9:32:90:ec:09:3c [router]
10.2.2.0/24 > 10.2.2.203 » [endpoint.new] endpoint 10.2.2.209 detected as 00:50:e4:13:ae:58 (Apple, Inc.)

Then he sets the target and turns spoofing on. arp.spoof.fullduplex true is the part that matters: without it bettercap only poisons the victim, so it sees the victim’s outbound traffic but the return path still goes straight to the gateway. Full-duplex poisons the gateway too, and now he’s in both directions.

10.2.2.0/24 > 10.2.2.203 » set arp.spoof.targets 10.2.2.209
10.2.2.0/24 > 10.2.2.203 » set arp.spoof.fullduplex true
10.2.2.0/24 > 10.2.2.203 » arp.spoof on
10.2.2.0/24 > 10.2.2.203 » [sys.log] [inf] arp.spoof enabling forwarding
10.2.2.0/24 > 10.2.2.203 » [sys.log] [inf] arp.spoof arp spoofer started, probing 1 targets.

At this point he can see everything the professor sends in plaintext. The problem is that the interesting traffic, the faculty portal login, isn’t plaintext.

The TLS problem

HTTPS is supposed to make this whole exercise pointless. The point of TLS is that being in the middle doesn’t help you: the session is encrypted end-to-end, and, crucially, the server proves its identity with a certificate signed by an authority the browser already trusts. You can relay the ciphertext all day; you can’t read it, and you can’t impersonate media.waitla.edu because you don’t hold a certificate for it that any browser will accept.

So to read the login, you have to break the identity check, not the encryption. You terminate the victim’s TLS connection at your machine and open a fresh one to the real server. To the victim, you have to look like media.waitla.edu. That means presenting a certificate for *.waitla.edu. And you can’t get a real one.

The rogue certificate

bettercap’s https.proxy handles this. When it intercepts a new TLS connection it mints a certificate for the requested host on the fly, signed by its own certificate authority (by default ~/.bettercap-ca.cert.pem, generated the first time it runs). The cryptography is perfectly valid. The chain is not: it terminates at a CA that the victim’s browser has never heard of and does not trust.

10.2.2.0/24 > 10.2.2.203 » set https.proxy.sslstrip false
10.2.2.0/24 > 10.2.2.203 » https.proxy on
10.2.2.0/24 > 10.2.2.203 » net.sniff on
10.2.2.0/24 > 10.2.2.203 » [sys.log] [inf] https.proxy started on 10.2.2.203:8083
10.2.2.0/24 > 10.2.2.203 » [sys.log] [inf] https.proxy creating spoofed certificate for *.waitla.edu:443

So the browser does exactly what it’s supposed to do: it throws a certificate warning. This connection is not private. The certificate is not trusted. Everything is working as designed. The security model is intact right up to the last component in the chain, the human, and the human has been clicking through this exact warning on this exact portal since roughly 2029, because the portal never fixed its certificate and he just wants his slides.

He clicks through. He types his credentials. They land in the sniffer in cleartext.

[22:34:49] [net.sniff.http] http POST media.waitla.edu/login.aspx
Host: media.waitla.edu
Content-Type: application/x-www-form-urlencoded

fac_username=ADietrich&fac_password=Unix1972&login=Submit

(bettercap can also do this the lazy way, https.proxy.sslstrip true, which doesn’t spoof a certificate at all. It rewrites links so the victim’s browser is steered to plaintext http:// and never negotiates TLS in the first place. No warning, just a missing padlock nobody checks. The rogue-cert path is the one that survives when the victim actually reaches the HTTPS URL, which is why it’s the one that matters here.)

Why the warning is the whole game

Both variants die the instant the server does one thing: send an HSTS header. HTTP Strict Transport Security tells the browser “for this domain, HTTPS only, and remember it.” Two consequences kill this attack outright. First, sslstrip stops working: the browser refuses to make a plaintext request to a known HSTS host, so there’s nothing to downgrade. Second, and this is the important one: on an HSTS host, the browser does not offer the user a way to proceed past a certificate error. There is no “Advanced → Accept the Risk” button. The rogue certificate produces a hard wall, not a warning, and the professor’s decade of reflexive click-throughs buys him nothing.

The portal in the book has no HSTS. That single omission is the whole exploit. Everything upstream, the crypto Dietrich is lecturing about, the TLS handshake, the certificate math, is flawless. The gap is between what’s cryptographically true and what a tired human is willing to override.

The fix

  • Dynamic ARP Inspection (DAI) with DHCP snooping. On a managed switch, DHCP snooping builds a table of legitimate IP↔MAC↔port bindings, and DAI drops ARP packets on untrusted ports that don’t match it. Forged replies never reach the victim. This kills the attack at layer 2, before TLS is even in the picture.
  • 802.1X / port security. Authenticate devices to the switch port so an unknown laptop on a lecture-hall jack can’t join the faculty segment at all.
  • HSTS, ideally with preload. Make certificate errors non-bypassable, and get the domain onto the browser preload list so the very first visit is protected before any header is ever seen. includeSubDomains closes the wildcard gap.
  • Certificate pinning. For high-value clients, pin the expected certificate/key so a validly-signed-but-wrong cert is rejected regardless of what CA vouches for it.
  • A VPN on untrusted LANs. Tunnel the traffic so the local segment only ever sees ciphertext to a single endpoint.

The reality of today versus 2035 LA

I admit that, as an author, this attack is extremely dated and unlikely to work in most contexts today, because ARP spoofing has largely been dealt with by responsibly developed SMART switches which are capable of identifying and ignoring unsolicited ARP broadcasts from a single MAC address as obvious ARP spoofing attempts. The reason I wrote it, for those fellow cybersecurity lovers who I’m sure would relish the idea of tearing my work to pieces, is that in the world of 2035 Post-AI Bubble Crash and subsequent “Deletion Event”, much of the world’s cloud infrastructure, documentation, software and advanced AI technology, and by extension the advanced hardware and switching capability was left to languish and decay because of AI/Datacenter companies largely collapsing. This left institutions and future businesses that decided to continue surviving to fall back on older protocols, technology, hardware, and things that were able to be salvaged from the wreckage. Things that were not run or interfaced with by AI. Things that were disconnected entirely from the world, old Cisco Nexus switches, for example.

The plausibility of a lot of the hacking that is demonstrated in the world of Null Witness is purposely dated for multiple reasons:

  1. The attacks are well-documented, well-understood, and easy for me to replicate in the prose :wink:
  2. It is great world-setting material that reiterates the decayed state of technology in a post-AI world. This world has witnessed a sudden and catastrophic collapse, introducing old vulnerabilities and technology, and I wanted to share that image with people to show what we are likely to lose if we continue on the path we are.
  3. It makes Cade a lover of hacking, not a super-genius. The illusion of hacking fiction often characterizes the main protagonists as insanely hyper-intelligent wizards who walk through systems like open doors, when that is not who Cade is. He’s a human. Smarter than average, but not Einstein. He’s a young adult MIT dropout trying to survive using a skill he learned to use efficiently and with genuine interest when he was young. I think that makes him more human, relatable, and realistic as a character.

The point

Cade doesn’t break RSA. He doesn’t break TLS. He breaks the one assumption the whole edifice quietly rests on: that when the system says something is wrong here, the person on the other end will stop. The math was never the weak part. The math is never the weak part. Systems have edges, and the edge is almost always the place where a technically-correct warning meets a human who has learned that warnings are just noise. The padlock was always a suggestion. He just found the one person who’d been taking it that way for six years.

Sources & further reading