What Is a Man-in-the-Middle Attack?

A man-in-the-middle attack (MITM) is an attack where a third party secretly positions itself between two communicating parties, intercepting — and potentially altering — traffic that both sides believe is going directly to each other. Neither the client nor the server necessarily notices anything wrong, because the attacker often relays the traffic onward after reading or modifying it, so both ends of the conversation still appear to complete normally.

The basic mechanics

For a MITM attack to work, the attacker needs to get in the path of the traffic, then optionally decrypt or alter it. That breaks into two distinct steps:

1. Interception. The attacker gets network traffic routed through a system they control — by joining the same local network, poisoning ARP or DNS resolution so traffic gets misdirected, running a rogue Wi-Fi access point, or compromising a router along the path.
2. Decryption or manipulation. Once traffic flows through the attacker, encrypted connections are the real barrier. If the connection isn’t encrypted, the attacker reads everything in plaintext. If it is encrypted (as with HTTPS), the attacker has to either exploit a flaw in the encryption setup or trick one side into establishing a connection with them instead of with the real endpoint.

Common variants

• ARP spoofing. On a local network, the attacker sends forged ARP replies associating their own MAC address with another device’s IP address, causing traffic meant for that device to route through the attacker instead.
• DNS spoofing. The attacker corrupts DNS resolution so a domain name resolves to an IP address they control, redirecting a user to a malicious server that impersonates the real site.
• Rogue Wi-Fi access points. An attacker sets up an open or look-alike Wi-Fi network in a public location; anyone who connects has their traffic routed through the attacker’s equipment by default.
• SSL/TLS stripping. The attacker intercepts an initial unencrypted request (before it’s redirected to HTTPS) and relays it to the real site over a legitimate encrypted connection, while serving the victim a plaintext connection — reading everything the victim sends before it’s ever encrypted.
• Malicious or forged certificates. If an attacker can get a client to trust a certificate they control — through a compromised certificate authority, a device with a malicious root certificate installed, or a user clicking through a certificate warning — they can decrypt and re-encrypt TLS traffic transparently.

Why HTTPS alone doesn’t fully solve this

HTTPS and the TLS handshake are specifically designed to defeat MITM attacks: the server proves its identity with a certificate signed by a trusted certificate authority, and the resulting session key is only usable by the two endpoints that negotiated it. This is why TLS stripping targets the initial unencrypted connection rather than trying to break the encryption itself — it’s far easier to intercept a request before it’s upgraded to HTTPS than to defeat TLS once it’s established.

The remaining gap is trust in the certificate chain. If a device is tricked into trusting a certificate it shouldn’t — a compromised or coerced certificate authority, a corporate proxy with an installed root certificate, or a user ignoring a browser warning — an attacker can present a valid-looking certificate for a domain they don’t actually control, and the encrypted connection no longer protects against interception by that attacker.

Defenses that actually work

• HSTS. HTTP Strict Transport Security tells the browser to never connect to a domain over plain HTTP again, closing the window that SSL-stripping attacks depend on.
• Certificate pinning. An application hard-codes which certificate or public key it expects for a given server, rejecting connections signed by any other certificate authority — even a technically valid one.
• Mutual TLS. mTLS requires both the client and server to present certificates, so an attacker can’t simply impersonate a client to a server that verifies client identity as well.
• DNSSEC. DNSSEC cryptographically signs DNS records, making DNS spoofing far harder to pull off undetected.
• VPNs on untrusted networks. A VPN encrypts traffic between a device and a trusted endpoint before it ever touches an untrusted local network, neutralizing local ARP-spoofing and rogue-access-point attacks.
• Avoiding certificate warnings. The single most common way real-world MITM attacks succeed against individual users is a browser certificate warning being dismissed without a second thought — that warning exists specifically because something about the certificate chain didn’t validate correctly.
• Passkeys. Because passkeys are cryptographically bound to the origin they were created for, they can’t be phished or relayed to an attacker-controlled site the way a password typed into a convincing fake login page can.

Where this matters most

MITM risk is highest on networks you don’t control — public Wi-Fi, coffee shops, conference networks — and lowest on a trusted, encrypted connection to a service that enforces HSTS and validates certificates strictly. It’s also a meaningful concern inside corporate networks that deploy TLS-inspecting proxies, which are themselves a sanctioned, in-path man-in-the-middle — a reminder that the technique is a neutral capability, used defensively by security teams inspecting traffic just as often as it’s used offensively by attackers.

The takeaway

A man-in-the-middle attack works by getting traffic routed through an attacker-controlled point and then reading or altering it, either because the connection was never encrypted or because the attacker found a way around the encryption’s trust model. TLS defeats the interception itself, but the remaining risk is in the edges around it — unencrypted first requests, certificate warnings dismissed too casually, or a trust relationship (a rogue CA, a corporate root certificate) that shouldn’t exist. HSTS, strict certificate validation, mTLS, and avoiding untrusted networks without a VPN close most of the realistic attack paths.