Man-in-the-Middle Attack
What is a Man-in-the-Middle Attack?
A man-in-the-middle attack places an attacker between two parties who believe they are talking directly to each other. The attacker can read what passes, and in most cases alter it.
The attack is much less common against web traffic than it was, for one reason: HTTPS is now effectively universal, and TLS authenticates the server and encrypts the channel. Most of the classic scenarios described in security training require a connection that is either unencrypted or whose certificate warning the victim clicked through.
How interception is achieved
| Route | Mechanism | What defeats it |
|---|---|---|
| Hostile network | A public Wi-Fi access point the attacker controls | HTTPS, and HSTS so the first request is never plaintext |
| ARP or DNS poisoning | Redirecting local traffic to the attacker's machine | Certificate validation; DNSSEC and encrypted DNS |
| Downgrade | Forcing a plaintext connection before TLS is negotiated | HSTS with preloading, so the browser refuses plaintext |
| Rogue certificate authority | A certificate the browser trusts but the site never ordered | Certificate Transparency logs, and monitoring them |
| Compromised endpoint | Malware with a local root certificate installed | Nothing at the network layer; the device is the problem |
The last row is the one that still works reliably, and it is why endpoint compromise matters more than network position. An attacker on the device does not need to be in the middle of anything.
The version that affects authentication
The practically important case today is not packet interception, it is a phishing proxy. The victim visits a convincing replica, the replica relays every field to the real site in real time, and the session token that comes back is captured. Passwords and time-based one-time codes both fall to this, because both are just values that can be relayed within their validity window.
This is the attack that WebAuthn and hardware keys actually stop, and they stop it structurally rather than procedurally: the browser signs a challenge bound to the real origin, so the signature a relay captures is worthless on the genuine site. Nothing a user can be trained to notice is as reliable.
What this has to do with bot protection
Mostly it does not, and that is worth saying because the terms get bundled in security marketing. A CAPTCHA cannot prevent interception, and TLS cannot tell a script from a customer.
The one real intersection is the phishing proxy above. Those relays are automated, operate at scale, and have to replay captured sessions — so the bot layer that notices a session being used from somewhere implausible, or replayed, is doing something useful against this attack even though it is not a transport-security control. Keep the two straight: TLS and HSTS secure the channel, and origin-bound credentials are what make a relayed credential useless.