What Is a Man-in-the-Middle Attack

A man-in-the-middle (MITM) attack is one in which an attacker positions itself between two communicating parties and intercepts or tampers with the traffic passing through. Because the victim believes it is talking directly to the legitimate party, the attack is hard to notice.

For the attack to work, the attacker has to insert itself somewhere on the network path. Public Wi-Fi, ARP spoofing, and DNS spoofing are all ways of seizing a relay point. Since encryption with TLS/SSL became widespread, sitting on the path is no longer enough to read the traffic. What still leaves room for the attack is an unencrypted leg somewhere along the way, an application that skips certificate validation, and a user who ignores a certificate warning and connects anyway.

Common Attack Techniques

A handful of techniques account for most man-in-the-middle attacks.

ARP spoofing: Forged ARP (Address Resolution Protocol) packets are sent on the local network so that the MAC address of the peer is replaced with the attacker's. ARP has no mechanism for checking whether a reply really came from the sender it claims (RFC 826, a specification from 1982), so traffic from a host whose cache has been overwritten starts flowing through the attacker
DNS spoofing: DNS responses are forged so that a legitimate domain name resolves to the IP address of the attacker's server. The user believes they are visiting the correct URL but is taken to a fake site
SSL stripping: The attacker downgrades an HTTPS connection to HTTP, speaking HTTP with the client and HTTPS with the server in order to read the unencrypted side. For domains whose HSTS entry is built into the browser's preload list, HTTPS is enforced from the very first connection, which makes this technique much harder to pull off
Rogue Wi-Fi access points: In cafes, airports, and similar places, an access point with a name resembling the legitimate one is set up so that traffic from anyone who connects passes through the attacker's equipment. This is also called an Evil Twin attack. The contents of HTTPS-protected sessions stay unreadable, but the setup still allows metadata such as destination domains to be observed, and it gives the attacker a foothold for unencrypted traffic and for redirection to fake sites
BGP hijacking: The internet's routing protocol (BGP) is abused to divert traffic destined for particular IP addresses through the attacker's network. BGP was never designed to verify the origin of the route advertisements it receives, so the same kind of route leak also happens through configuration mistakes rather than intent. Origin validation with RPKI (RFC 6480, RFC 6811) has been built out as a countermeasure

Defense Strategies and the Importance of Encryption

Defending against man-in-the-middle attacks comes down to having both encryption of the traffic and authentication of the other party in place.

Communication Encryption

Use TLS 1.3: TLS 1.3 (standardized in RFC 8446 in 2018, with RFC 9846 of July 2026 as its revised edition) improves the handshake and is resistant to downgrade attacks. TLS 1.0 and TLS 1.1 are prohibited by RFC 8996 (2021), so disabling them is a given
HSTS (HTTP Strict Transport Security): Defined in RFC 6797 (2012), it instructs the browser to connect over HTTPS from then on. It blocks SSL stripping, but the very first connection, made before the instruction arrives, is not protected, so the gap is closed by registering the domain in the preload list shipped with browsers
Use a VPN: On untrusted networks such as public Wi-Fi, a VPN wraps all traffic in an encrypted tunnel. What it protects, however, is only the leg up to the VPN provider, and it also moves your trust from the network operator to that provider

Authentication and Verification

Certificate pinning: An application is configured to trust only a specific certificate or public key, so interception with a forged certificate fails. For browsers, HPKP (RFC 7469, 2015) carried the risk of putting a site out of reach if it was configured wrongly, and Chrome removed it in version 72 (January 2019). Pinning stays practical where the same developer controls both the distributed client and the endpoint it talks to, as with mobile apps
Mutual authentication with public key cryptography: Mutual TLS (mTLS) has the client present a certificate as well as the server, so both ends are authenticated
Deploy DNSSEC: Defined in RFC 4033 (2005) and the documents that followed, it attaches digital signatures to DNS responses so that their origin and integrity can be verified. It does not encrypt the contents of DNS, and forged responses are only rejected once signing on the zone side and validation on the querying side are both in place

Network-Level Measures

Dynamic ARP Inspection (DAI): A feature of switch products that validates ARP packets and blocks ARP spoofing
802.1X authentication: Devices are required to authenticate when they join the network, which keeps unauthorized ones off it

Practical Self-Defense on Public Wi-Fi

Public Wi-Fi is an easy foothold for man-in-the-middle attacks: anyone can join the same network, and the equipment on the path can be supplied by a third party. Since HTTPS became the default, the situations in which the contents of your traffic are read outright are limited. Even so, metadata such as the domains you connect to is visible from the path, and unencrypted traffic, clicking through a certificate warning, and being lured to a lookalike domain all remain as gaps. With a clear picture of what is protected and what is not, making the following measures routine reduces how often you touch the gaps that are left.

Keep a VPN on at all times: With VPN encryption, all that the equipment on the path can see is an encrypted tunnel, so even a connection through a rogue access point does not expose your traffic or the sites you reach
Turn off automatic connection: Disable automatic Wi-Fi joining on your phone and laptop so that you never end up on a network you did not choose
Always stop at a certificate warning: A warning is a direct sign that another party may have inserted itself on the path, so do not add an exception and push through. Conversely, a padlock in the address bar tells you the traffic is encrypted; it is not proof that the domain is the genuine one
Use an authentication method that fails on a lookalike domain: One application of the man-in-the-middle idea is adversary-in-the-middle (AiTM) phishing, in which the attacker puts a reverse proxy in front of the real site and relays the credentials and session cookie you enter as you type them. One-time passwords are simply relayed along, so what helps is a method whose signature does not validate on a fake domain, such as passkeys (FIDO2), where the key is bound to the domain of the genuine site
Avoid sensitive operations: Do online banking and logins to important accounts from a network you trust
Watch out for DNS leaks: Even with a VPN in use, DNS queries are sometimes sent over an unencrypted path. Check with a DNS leak test

A man-in-the-middle attack succeeds when you keep communicating without ever confirming that the other end is genuine. Encrypt to protect the contents, use certificates to confirm who you are talking to, and stop when a warning appears. Whether all three are in place is what makes the difference.

Common Misconceptions

HTTPS makes MITM attacks impossible: HTTPS is a strong defense when properly implemented, but MITM attacks can still succeed when applications ignore certificate validation, use outdated TLS versions, or users dismiss certificate warnings.
MITM attacks require being on the same Wi-Fi network: ARP spoofing is a local network attack, but DNS spoofing and BGP hijacking can be executed remotely. ISP-level traffic interception and malware-based proxy configuration changes are among many techniques that do not require physical proximity.

Man-in-the-Middle Attack (MITM)