Man-in-the-Middle: On-Path Interception & TLS Defense

Two computers exchange messages and each assumes it is talking straight to the other. A man-in-the-middle attack breaks that assumption. The attacker slips onto the path between them, relays the traffic in both directions, and reads or rewrites it along the way. Both endpoints see a working connection. Neither sees the extra hop.

The technique is old and the defense is well understood, yet interception still works often enough to matter. It works because the hard part is not the interception itself. It is getting into the middle of the conversation in the first place, and networks hand attackers several ways to do exactly that.

The core idea

A man-in-the-middle attack, which MITRE ATT&CK catalogues as Adversary-in-the-Middle (T1557), has two moving parts.

The first is positioning. The attacker has to sit somewhere the traffic actually passes through, so that packets from the client flow to the attacker before they reach the server, and back again. This is the on-path requirement, and everything depends on it.

The second is relay. Once on-path, the attacker forwards traffic between the two parties. If the relay is passive, they only read what goes by. If it is active, they modify requests and responses: swapping a payment address, injecting a script into a page, stripping a security header, capturing a login. To each endpoint the connection looks normal because the attacker keeps it flowing.

Confidentiality and integrity both fall in an active MITM. The attacker sees the data and can change it, and neither side has a built-in way to notice unless the traffic was authenticated.

How attackers get on-path

Positioning is where the real work happens. A few reliable techniques put an attacker in the middle, each operating at a different layer.

• ARP spoofing. On a local network, an attacker forges ARP replies so that other hosts associate the attacker's MAC address with the gateway's IP. Traffic meant for the router flows through the attacker instead. This is the classic LAN interception move.
• DNS spoofing. If the attacker can forge or poison DNS answers, they steer a victim's hostname lookups to an IP they control. The victim connects to the attacker's server thinking it is the real one.
• Rogue access points. A malicious Wi-Fi access point advertising a familiar network name convinces devices to associate with it. Every packet then transits the attacker's hardware.
• LLMNR and NBT-NS spoofing. On Windows networks, name-resolution fallbacks can be answered by an attacker, redirecting connections and harvesting authentication material.
• Route and BGP manipulation. At the internet scale, an attacker who can influence routing announcements can pull traffic for whole prefixes through infrastructure they control.

Each of these is a separate discipline, but they share one goal: make the victim's traffic pass through the attacker before it reaches its destination.

Technique	Layer	Where it works	Primary defense
ARP spoofing	Link (L2)	Local LAN segment	Dynamic ARP Inspection, static entries
DNS spoofing	Application	Resolver and cache path	DNSSEC, encrypted DNS
Rogue access point	Link (L2)	Wireless range	802.1X, verified SSIDs, VPN
LLMNR/NBT-NS spoofing	Application	Windows name resolution	Disable LLMNR/NBT-NS
BGP hijack	Network (L3)	Inter-domain routing	RPKI, route filtering

Why plaintext protocols make it trivial

When traffic is unencrypted, an on-path attacker wins outright. Plain HTTP, old mail protocols without TLS, and any cleartext session hand over their contents to anyone in the middle. Reading is free and rewriting is only slightly harder. There is no cryptographic check that would reveal the tampering, so the endpoints accept whatever the attacker sends.

This is why interception was so productive in the era of widespread plaintext. The attacker did not need to break anything. They only needed to be in the path, and the data was right there.

Why TLS is the answer

Transport Layer Security, defined for its current version in RFC 8446, is built to survive exactly this threat model. It assumes the network is hostile and that an attacker may sit on the path. TLS provides three things that break a MITM:

• Authentication. During the handshake the server presents a certificate signed by a trusted certificate authority. The client checks that the certificate matches the hostname it intended to reach and chains to a CA it trusts. An attacker relaying the connection cannot present a valid certificate for a name they do not control, so impersonation fails.
• Confidentiality. The session is encrypted with keys negotiated during the handshake. An on-path attacker sees ciphertext and nothing more.
• Integrity. Every record carries authentication data. If the attacker flips a byte in transit, the receiving side detects it and tears the connection down.

Put together, these mean an attacker who is perfectly positioned on the path still cannot read the plaintext, cannot forge the server's identity, and cannot silently alter the data. The on-path position, so hard to reach, buys almost nothing against correctly validated TLS.

Where TLS still leaves gaps

TLS defeats interception only when it is actually in force and actually validated. The remaining exposure lives in the edges.

• The plaintext first moment. If a user types a bare hostname, the browser may make an initial plain HTTP request before any redirect to HTTPS. An on-path attacker can intercept that request and keep the victim on HTTP, a technique called SSL stripping. The fix is HSTS and preload, which tell the browser to use HTTPS from the very first byte.
• Skipped validation. Applications that disable certificate checks, trust any certificate, or ignore hostname mismatches throw away the authentication that makes TLS work. A MITM with any certificate then walks straight in.
• Untrusted root certificates. If an attacker can install their own CA in the victim's trust store, they can mint certificates that validate. This is how corporate inspection proxies work, and how malware performs interception on a compromised host.
• Downgrade attempts. Pushing a connection to a weaker protocol version or cipher can expose it. Modern TLS negotiation resists this, which is one reason to disable old versions entirely.

The pattern is consistent. TLS holds when it runs and validates properly. The attacks that remain go after the moments it is not yet running or the checks that were switched off.

How to defend against man-in-the-middle attacks

Defense works on two fronts: make on-path positioning harder, and make the position worthless when an attacker reaches it.

1. Encrypt everything with authenticated TLS. Serve all web traffic over HTTPS, use TLS for mail and internal services, and follow current guidance such as NIST SP 800-52 Rev. 2 for protocol versions and cipher choices. Disable TLS 1.0 and 1.1.
2. Turn on HSTS and submit to preload. This removes the plaintext first request and closes the SSL stripping window. See our related guide on HSTS below.
3. Validate certificates strictly. Never disable certificate or hostname verification in application code. Treat any temptation to do so as a defect to fix, not a shortcut.
4. Harden the local network. Enable Dynamic ARP Inspection and DHCP snooping on managed switches to blunt ARP spoofing. Disable LLMNR and NBT-NS where they are not needed.
5. Protect name resolution. Use DNSSEC-validating resolvers and encrypted DNS so that lookups cannot be silently redirected.
6. Consider pinning and mutual TLS. Certificate pinning ties a client to a known certificate or key, defeating rogue-CA interception. Mutual TLS authenticates both ends and suits service-to-service traffic.
7. Use a trusted VPN on hostile networks. On public Wi-Fi where rogue access points are a real risk, a VPN wraps everything in an authenticated tunnel back to a known endpoint.

For the wider picture of how these interception techniques show up across real campaigns and which groups favor them, our Threat Group Directory maps adversaries to the on-path methods they use.

A worked example: ARP spoofing to a stripped login

Follow one intrusion from positioning to payoff to see how the pieces combine on a local network. The attacker is on the same LAN segment as the victim, perhaps through a compromised device or a network port in a shared space. The goal is to capture a login the victim submits to a web application.

First, positioning. The attacker sends forged ARP replies onto the segment. One tells the victim that the gateway's IP address belongs to the attacker's MAC address. Another tells the gateway that the victim's IP belongs to the attacker's MAC. ARP has no authentication, so both machines update their caches and begin sending frames to the attacker. The attacker enables forwarding so traffic still reaches its real destination, keeping the connection alive and the victim unaware. The attacker is now on-path in both directions.

Second, the plaintext moment. The victim opens a browser and types a bare hostname with no scheme. The browser makes an initial plain HTTP request before any redirect to HTTPS can happen. The attacker, sitting on the path, answers that request itself instead of letting the redirect through, keeping the session on HTTP. This is SSL stripping: the victim sees a working page, possibly with the expected content proxied from the real site, but the connection is plaintext the whole way.

Third, the payoff. The victim types a username and password into the login form and submits. Because the session was never upgraded to HTTPS, the credentials cross the wire in the clear, straight through the attacker's machine, which records them before forwarding the request to the real server. The victim logs in successfully and notices nothing.

Now replay the same scenario with defenses in place. If the site is on the HSTS preload list, the browser refuses to make that first plain HTTP request at all and goes straight to HTTPS, so there is no plaintext moment to hijack. If the attacker tries to present their own certificate for the site, validation fails because they do not control a certificate the victim's trust store accepts, and the browser refuses to connect. If the switch runs Dynamic ARP Inspection, the forged ARP replies are dropped before positioning even succeeds. Each defense removes one link, and any single removed link breaks the chain.

Detection signals

MITM activity is often quiet, but it disturbs the network and the endpoints in ways a defender can watch for.

• ARP anomalies. The gateway IP suddenly mapping to a new MAC address, two IPs sharing one MAC, or a burst of unsolicited ARP replies all point at ARP spoofing. Dynamic ARP Inspection logs these directly.
• Certificate changes and warnings. A certificate that suddenly differs from the expected one, is issued by an unexpected authority, or triggers a validation warning is a strong signal that something is terminating TLS in the middle. Pinning turns this into a hard failure.
• Unexpected protocol downgrades. A session that should be HTTPS arriving over HTTP, or a connection negotiating an older, weaker TLS version than usual, suggests a stripping or downgrade attempt.
• Duplicate or rogue infrastructure. A second device answering DHCP, an access point broadcasting a familiar network name from an unexpected location, or a new default gateway all indicate positioning attempts.
• Latency and path changes. Interception adds a hop. Unexplained added latency, or a traceroute that suddenly routes through an unexpected node, can betray an on-path relay, especially at the routing scale.
• Name-resolution surprises. A hostname resolving to an unfamiliar IP, or internal name-resolution fallbacks like LLMNR being answered by an unexpected host, point at DNS or name-service spoofing.

Passive versus active interception

Not every MITM does the same thing once on-path, and the distinction shapes both impact and detection.

Property	Passive interception	Active interception
What the attacker does	Reads traffic as it passes	Reads and modifies traffic
Effect on data	Confidentiality lost	Confidentiality and integrity lost
Examples	Sniffing plaintext, logging credentials	SSL stripping, injecting scripts, swapping a payment address
Detectability	Very low; leaves little trace	Higher; changes to content or certificates can be caught
Defeated by	Encryption alone	Encryption plus authentication and integrity

The table explains why authenticated encryption, and not encryption by itself, is the real answer. Encryption alone stops passive reading. Authentication and integrity are what stop the active attacker from impersonating an endpoint or altering data undetected. TLS provides all three, which is why a correctly validated TLS session defeats both columns at once.

How the threat evolved

Interception used to be easy because the web ran on plaintext. For years most web traffic, most email, and most internal protocols crossed the network in the clear, so an on-path attacker simply read what went by. The defensive answer arrived in stages. Encryption became widespread, which stopped passive reading, but early deployment left gaps: sites offered HTTPS as an option a user had to reach rather than a default, which is exactly the opening SSL stripping exploited. HSTS and later the preload list closed that gap by making HTTPS the mandatory first move for participating sites.

Certificate trust was the next battleground. Interception shifted from reading plaintext to trying to impersonate the server, which put pressure on how certificates are issued and validated. Stricter validation, public logs that make certificate misissuance visible, and pinning for high-value clients raised the cost of presenting a fraudulent certificate. TLS itself was tightened, with the current version removing weak options that downgrade attacks had leaned on. The pattern mirrors the rest of security: as the plaintext era closed, interception migrated to the edges, the plaintext first request and the validation step, so modern defense concentrates on removing those edges rather than on the interception itself.

Common misconceptions

"HTTPS in the address bar means I am safe from MITM." HTTPS protects a session that actually negotiated and validated TLS. If an attacker stripped the connection to HTTP, or the application skipped certificate validation, or a rogue root certificate is trusted, the padlock story falls apart. The protection depends on validation being real, not on the scheme being requested.

"MITM requires breaking encryption." Against plaintext it requires no cryptography at all, only an on-path position. Against TLS the attacker usually does not break the math; they target the plaintext moment before TLS starts or a validation check that was switched off. Interception is about position and trust, not about defeating ciphers.

"Only public Wi-Fi is risky." On-path positioning happens on wired LANs through ARP spoofing, on Windows networks through name-resolution spoofing, and at internet scale through routing manipulation. Public Wi-Fi is one venue among several, and a trusted network can host an on-path attacker just as easily.

"A VPN makes me immune everywhere." A trusted VPN wraps traffic in an authenticated tunnel to a known endpoint, which defeats interception on the local network. It does not protect the segment beyond the VPN exit, and it depends on the VPN's own authentication being sound. It is a strong control on hostile networks, not a universal shield.

"If TLS were being intercepted, I would get an error." You get an error only when validation actually runs and fails. If a rogue certificate authority is trusted, or the application ignores validation, interception proceeds with no warning at all. Silence is not proof of safety.

Frequently asked questions

What is a man-in-the-middle attack? It is an attack where the adversary positions themselves on the network path between two parties and relays the traffic while reading or altering it, so both sides believe they are communicating directly with each other. MITRE ATT&CK catalogues it as Adversary-in-the-Middle.

What is the difference between passive and active MITM? A passive attacker only reads the traffic that passes through, losing the victim's confidentiality. An active attacker also modifies it, which additionally breaks integrity and enables tricks like stripping encryption, injecting content, or swapping data in transit.

How does TLS stop a man-in-the-middle? TLS authenticates the server through a certificate that chains to a trusted authority and matches the requested hostname, encrypts the session so an on-path attacker sees only ciphertext, and adds integrity checks so any tampering is detected. An attacker relaying the connection cannot present a valid certificate for a name they do not control, so impersonation fails.

What is SSL stripping and how do I prevent it? SSL stripping keeps a victim on plain HTTP by intercepting the initial plaintext request before the redirect to HTTPS. HSTS instructs the browser to use HTTPS from the first byte, and the preload list bakes that instruction in before the first visit, removing the plaintext moment the attack needs.

Can a VPN protect me from MITM on public Wi-Fi? Yes, on that network. A trusted VPN builds an authenticated encrypted tunnel to a known endpoint, so a rogue access point or an ARP-spoofing neighbour sees only tunnel traffic. Protection ends at the VPN exit, and it depends on the VPN client validating its own server correctly.

Why is certificate validation so important? Validation is the step that ties the encrypted session to the identity of the party you meant to reach. Without it, an attacker can present any certificate and the encryption simply protects a conversation with the wrong party. Disabling certificate or hostname checks throws away the authentication that makes TLS resistant to interception.

Does encrypted DNS stop man-in-the-middle attacks? Encrypted DNS protects the confidentiality and integrity of name lookups, which blocks the DNS-spoofing path to on-path positioning. It does not by itself protect the subsequent connection; that is TLS's job. The two work together, one securing where you connect and the other securing the connection itself.

A man-in-the-middle attack is only as strong as the traffic it intercepts. Against plaintext it is total. Against properly validated TLS it collapses into a listener who sees ciphertext and cannot change a thing. Encrypt everything, authenticate both ends, close the plaintext gaps, and the hard-won on-path position stops paying off.

Related guides

• SSL Stripping Explained
• ARP Spoofing Explained
• How HTTPS Works
• How the TLS Handshake Works