Man-in-the-Middle

A man-in-the-middle (MITM), or more generally an on-path, attack happens when an attacker gains a position between communicating parties and can observe, relay, redirect, or modify traffic.

The important qualification is that being on-path does not automatically break modern TLS. A correctly authenticated HTTPS connection is specifically designed to remain confidential and integrity-protected even when the network between client and server is hostile.

For runtime tampering on the endpoint rather than in-flight interception, see Friday Frida Hacking without the Why. For the broader mobile trust-boundary model, see Modern Mobile Hardening.

What an On-Path Attacker Actually Gets

An attacker who controls or influences a network path can often observe metadata and manipulate traffic that is not cryptographically protected. The exact capability depends on where the attacker sits and which protocols are in use.

Common techniques include:

ARP spoofing on an IPv4 local network
malicious or compromised Wi-Fi access points
DNS manipulation when DNS authenticity/privacy is not otherwise protected
routing or gateway compromise
interception of plaintext HTTP or other unencrypted protocols
presenting a TLS interception certificate when the client has been configured to trust the attacker’s CA

What the attacker cannot simply do is decrypt a normal HTTPS connection by virtue of forwarding its packets. To inspect or modify authenticated TLS, the attacker also needs a trust failure, endpoint compromise, exploitable protocol or implementation flaw, or some other way around certificate validation.

A Safe Lab Model

The safest place to learn these mechanics is an isolated virtual network you control. A useful lab has three roles:

Victim — a browser or test client.
Server — a service you own, with both deliberately insecure HTTP and properly configured HTTPS cases.
Attacker/router — a host placed on-path so packet forwarding, ARP manipulation, DNS experiments, and proxy behavior are observable.

The educational value is comparing the failure cases:

plaintext HTTP can be read or modified directly
an initial HTTP navigation can be prevented from upgrading to HTTPS
a client that trusts a lab CA can be transparently proxied in the lab
direct HTTPS with correct certificate validation resists ordinary on-path interception

That last case is just as important as demonstrating the attack.

SSL Stripping Is an Upgrade Attack

An older version of this article implied that an attacker could take a victim who had already established HTTPS and simply “strip” TLS. That is incorrect.

SSL stripping targets the transition from HTTP to HTTPS. If the user’s first request is plaintext HTTP and the server normally redirects to HTTPS, an on-path attacker can attempt to suppress or rewrite that redirect and keep the victim on plaintext HTTP.

HTTP Strict Transport Security (HSTS) reduces this downgrade opportunity by telling the browser to use HTTPS directly for future connections. Preloading can protect the first visit as well.

The practical rule is straightforward: do not treat an HTTP-to-HTTPS redirect as the security boundary. Prefer HTTPS from the beginning, remove unnecessary cleartext paths, and use HSTS where appropriate.

Network Layer

IPv4 and IPv6 Neighbor Discovery

ARP spoofing is a familiar IPv4 local-network technique because ARP maps IPv4 addresses to link-layer addresses without authentication.

IPv6 does not use ARP. Its Neighbor Discovery protocol combines several functions, including link-layer address discovery, router discovery, and reachability tracking. That is a different protocol model, not an automatic security upgrade: Neighbor Discovery has its own threats and operational controls.

The old article also described Multicast Listener Discovery as a replacement for router discovery. That was incorrect. Router Solicitations and Router Advertisements are part of IPv6 Neighbor Discovery itself.

IPsec

IPsec operates at the IP layer and can provide confidentiality, integrity, authentication, and access-control properties depending on the selected protocol and configuration.

It supports transport and tunnel modes. In transport mode, protection primarily covers upper-layer payloads; in tunnel mode, an entire inner IP packet is encapsulated and protected. VPNs commonly use tunnel-style designs, but IPsec is not accurately described as “protecting end-to-end inside TCP packets.”

Transport and Application Layer

TLS is the primary protection for ordinary web and API traffic. The important controls are less exotic than many MITM diagrams suggest:

use HTTPS consistently and avoid cleartext fallback
validate certificate chains and hostnames correctly
keep TLS libraries and server configuration current
avoid custom certificate-validation code unless the threat model requires it
protect authentication tokens and sessions at the application layer
assume an endpoint may eventually be compromised even if the network channel is sound

Certificate Pinning

Pinning can reduce dependence on the broad public CA ecosystem for selected high-risk applications, but it adds operational failure modes. Android’s Network Security Configuration requires planning for backup pins and rotation because a bad pinning strategy can lock legitimate clients out of a service.

Pinning therefore belongs to a specific threat model; it is not a universal replacement for correct TLS validation.

Endpoint Trust Is a Different Boundary

A network can be cryptographically sound while the client itself is hostile. Rooted devices, runtime instrumentation, malware, malicious accessibility services, repackaged applications, or compromised credentials can all move the attacker inside the TLS endpoint.

At that point, stronger network encryption does not restore trust. Sensitive systems need server-side authorization and validation, bounded session credentials, abuse detection, and—where justified—app/device integrity signals.

This is why mobile hardening and MITM defense should be treated as related but separate controls.

Detection and Observability

There is no generic “MITM detector” that reliably identifies every on-path attacker. Useful evidence tends to be specific to the system:

unexpected certificate or trust-chain changes
DNS or route changes that violate known policy
authentication/session anomalies
impossible or suspicious backend behavior
integrity verdict changes from managed or mobile clients
network telemetry from infrastructure you actually control

Latency alone is weak evidence. Good observability helps investigation, but it does not replace authenticated protocols.

Conclusion

The useful mental model is not “the network is trusted until a MITM appears.” It is the opposite: treat the network as untrusted and make authentication, confidentiality, integrity, and authorization survive that assumption.

The hierarchy is roughly:

eliminate unnecessary plaintext traffic
authenticate and encrypt transport correctly
remove downgrade paths
keep authorization and validation on the server
treat endpoint integrity as a separate risk signal
collect evidence that can explain suspicious behavior after the fact

An attacker who controls the path should be able to forward packets. That should not be enough to become either endpoint.

Use interception techniques only on systems and networks you own or are explicitly authorized to test.

References

Author Background

LinkedIn: Ryan Jennings for the broader professional background behind the applied security perspective in this article.