Part 9 — Network security

TLS and SSH secure individual connections. This Part is about the network they run on: how an attacker who controls a hop sniffs, spoofs, and redirects traffic — and how DNS security, segmentation, firewalls, and VPNs contain that.

Chapter 37 — The network attacker: sniffing, spoofing, MITM

In one sentence

A network attacker's power depends on their position — passively on the path, actively on the path, or off the path having to spoof their way in — and every defence in this Part is about shrinking what each position buys them.

Attacker positions (this framing runs through the whole Part)

   PASSIVE ON-PATH  -- can READ every packet, cannot change or inject.
                       A tap on a fibre; port mirroring; promiscuous Wi-Fi.
                       Beats: plaintext protocols. Defeated by: TLS/SSH
                       confidentiality (but traffic analysis still leaks).

   ACTIVE ON-PATH (MITM) -- can read, DROP, MODIFY, INJECT, DELAY.
                       A compromised router/switch/AP; ARP or DHCP spoofing
                       on a LAN; a malicious ISP; BGP hijack.
                       Beats: unauthenticated key exchange, downgrade-prone
                       protocols. Defeated by: authentication (certs, host
                       keys, HSTS) + integrity (AEAD).

   OFF-PATH        -- sees nothing, must GUESS/SPOOF (source IP, sequence
                       numbers, DNS transaction IDs, ports).
                       Beats: protocols with predictable identifiers or no
                       source validation. Defeated by: randomised IDs,
                       ingress/egress filtering, encryption.

Ask of any attack: which position does it need? It tells you the fix.

Layer 2 (LAN) attacks

On a shared local network, an active attacker has cheap ways to become MITM:

   ARP SPOOFING / POISONING
     ARP maps IP -> MAC and has NO authentication. Attacker broadcasts
     "10.0.0.1 (the gateway) is at MY mac". Victims update their ARP cache
     and send all gateway-bound traffic to the attacker, who forwards it on.
     -> full active MITM for the subnet. Tools: arpspoof, bettercap, ettercap.

   DHCP SPOOFING (rogue DHCP)
     Attacker answers DHCP faster than the real server, hands out ITSELF as
     the default gateway and/or DNS. Same outcome: MITM.

   MAC FLOODING
     Flood the switch's CAM table until it "fails open" and floods all
     frames to every port -> the switch behaves like a hub -> passive
     sniffing of everyone.

   STP / LLMNR / NBT-NS / mDNS poisoning
     Windows name-resolution fallbacks with no auth -> Responder-style
     attacks capture NTLM hashes. VLAN hopping via DTP / double-tagging.

   ROGUE / EVIL-TWIN ACCESS POINT
     Broadcast the same SSID as the corporate/coffee-shop Wi-Fi with a
     stronger signal. Clients auto-associate. Attacker is now the network.

Defences (switch/network side):

   Dynamic ARP Inspection (DAI)  -- drop ARP replies that don't match a
                                    trusted DHCP-snooping binding table
   DHCP Snooping                 -- only allow DHCP offers from trusted ports
   Port Security                 -- limit MACs per port; sticky MACs
   802.1X / MACsec               -- authenticate the DEVICE before the port
                                    is usable; encrypt the link layer
   Disable DTP; prune VLANs; put unused ports in a black-hole VLAN
   Client isolation on guest Wi-Fi; WPA3-Enterprise; disable LLMNR/NBT-NS

Host-side, the pragmatic truth: you often can't control the LAN (coffee shop, conference, a client site). So the working assumption is the local network is hostile, and your protection is end-to-end: TLS with verification, SSH host-key checking, a VPN, HSTS, DoH/DoT for DNS.

On-path MITM against TLS — why it (mostly) fails

An active attacker who intercepts your HTTPS connection must present some certificate for the site. Their options:

   * self-signed / wrong-name cert   -> browser refuses, no click-through
                                        under HSTS (Ch 31)
   * a REAL cert from a CA           -> they'd need to trick a CA into
                                        mis-issuing; CT (Ch 30) makes it
                                        detectable fast
   * a cert from a CA THEY CONTROL that's in your trust store
                                     -> this is exactly how corporate TLS
                                        inspection ("SSL/TLS interception")
                                        works: an internal root is pushed to
                                        managed devices. On such a device the
                                        padlock is real but the traffic IS
                                        being read by your employer's proxy.
   * strip TLS entirely (sslstrip)   -> only works if you first reach the
                                        site over HTTP; HSTS + preload kills
                                        it.

So: MITM on TLS requires a trust-store foothold or a CA failure. That's the whole point of Parts 5–7.

Off-path attacks worth knowing

   TCP sequence prediction / RST injection
     Off-path attacker guesses the 32-bit sequence number to inject data or
     forge a RST (connection reset). Modern stacks randomise ISNs; still
     used for censorship (the "Great Firewall" injects RSTs).

   DNS cache poisoning (Kaminsky, 2008) -- Chapter 38.

   BGP HIJACKING
     An AS announces routes for prefixes it doesn't own; traffic worldwide
     detours through it. Used to steal crypto (Amazon Route 53, 2018),
     intercept traffic, or just black-hole it. Defences: RPKI ROV (route
     origin validation), IRR filtering, peer prefix limits. As a service
     operator you also mitigate with TLS everywhere + DNSSEC + monitoring.

   IP SPOOFING + amplification (DDoS)
     Forge the victim's source IP, send small queries to servers (DNS, NTP,
     memcached, CLDAP) that reply with much larger responses AT the victim.
     Defence: BCP 38 / uRPF ingress filtering at every network edge;
     don't run open resolvers/reflectors.

Practice (30 min) — safe, on your own machine/lab only

# 1. See who's on your LAN and your ARP table (read-only)
arp -a
ip neigh 2>/dev/null || arp -an
#   note: ARP has no auth -- any of these entries could be spoofed.

# 2. Passive capture: watch DNS + plaintext on your own interface
sudo tcpdump -i any -n -s0 'udp port 53' -c 20
sudo tcpdump -i any -n -A 'tcp port 80' -c 40        # see plaintext HTTP

# 3. Prove TLS resists a passive sniffer: capture your own HTTPS and try
#    to read it
sudo tcpdump -i any -w /tmp/h.pcap 'host example.com and tcp port 443' -c 60 &
curl -s https://example.com -o /dev/null; sudo pkill tcpdump
#    open /tmp/h.pcap in Wireshark -> only ClientHello/ServerHello readable.

# 4. Detect a (simulated) MITM: pin then compare a cert fingerprint
echo | openssl s_client -connect example.com:443 -servername example.com \
  2>/dev/null | openssl x509 -noout -fingerprint -sha256
#    run this from two networks (home, phone hotspot) -- fingerprints must match.

# 5. Are you behind TLS interception right now? Check your trust store for
#    unexpected roots.
security dump-keychain 2>/dev/null | grep -i "labl" | grep -iE "proxy|zscaler|bluecoat|netskope|forcepoint|corp" || echo "no obvious interception root (macOS)"
#   Linux: ls /usr/local/share/ca-certificates/  and  /etc/ssl/certs

Lab-only (isolated VMs you own): run bettercap or arpspoof between two VMs on a host-only network, watch one become MITM, then enable Dynamic ARP Inspection (or static ARP entries) and watch it fail. Never on a network you don't own — Chapter 0.6.

Common confusions

"I'm on HTTPS so hostile Wi-Fi can't hurt me." Mostly true for confidentiality/integrity of each connection — but DNS, SNI, traffic size, and any HTTP-first request still leak, and a captive portal / evil twin can still ruin your day. A VPN narrows this.
"ARP spoofing is old / patched." ARP has no authentication; it's mitigated by switch features you may not control. On an untrusted LAN it's live.
"Corporate TLS inspection breaks TLS security." It relocates the trust boundary: your employer's proxy is a sanctioned MITM via a root on your managed device. The crypto is intact; the endpoint you're trusting changed.
"Off-path attackers are harmless." Sequence/ID prediction, DNS poisoning, and BGP hijacks are all off-path and all serious.

Check yourself

Define the three attacker positions and give one attack and one defence for each.
Why does ARP spoofing work, and what switch feature stops it?
What must an active attacker obtain to MITM a TLS connection to an HSTS-preloaded site?
How does corporate "TLS inspection" actually work, and is the padlock lying?
What is a BGP hijack, and name one real incident.

(Answers: Appendix F.)