Man-in-the-Middle Attack (MITM, on-path attack)

In a man-in-the-middle (MITM) attack, also called an on-path attack, the attacker gets into the communication path, for example through a rogue Wi-Fi access point, ARP spoofing on a LAN, DNS spoofing or a BGP route hijack, and relays traffic between client and server. Against unencrypted protocols this gives full read and write access. TLS is designed to defeat it: the server must prove possession of the private key for a certificate that covers the requested name and chains to a CA the client trusts, and the handshake transcript is authenticated so that tampering is detected.

Why it matters

Practical MITM against TLS therefore targets the edges of that model. Attackers rely on users clicking through certificate warnings, on clients that skip verification (curl -k, verify=False), on SSL stripping before TLS starts, on downgrade attacks to weak protocol versions, or on a fraudulently issued certificate. The 2011 compromise of the Dutch CA DigiNotar, which issued a fake certificate for google.com and was then removed from browser trust stores, is the classic example of the last case. HSTS, Certificate Transparency and CAA records exist largely to close these gaps.

Example

The most common self-inflicted MITM exposure is disabled verification:

curl -k https://api.example.com/                         # accepts ANY certificate: avoid
curl --cacert internal-ca.pem https://api.example.com/   # trust a specific CA instead

Common misconceptions

• HTTPS makes MITM impossible. Only if the client validates the certificate and the user does not override warnings.
• An attacker has to be physically nearby. DNS spoofing and route hijacks work remotely, and a compromised router or proxy sits on the path permanently.
• Skipping verification is fine for internal APIs. Skipping verification removes exactly the protection against MITM; trust the internal CA explicitly instead.