A man-in-the-middle (MitM) attack is when an attacker secretly positions themselves between two parties — typically a user and a website — and intercepts, reads or modifies the communication without either side knowing. The victim thinks they're talking directly to the bank, the shop or the email server. In reality, every byte passes through the attacker first.
How a MitM attack works
The attack has two stages:
- Interception — the attacker inserts themselves into the communication path. Common methods: ARP spoofing on a local network (poisoning the address table so traffic routes through the attacker's machine), rogue Wi-Fi hotspots (a fake "Free Airport WiFi" access point that the victim connects to), DNS spoofing (poisoning a resolver so your domain resolves to the attacker's server) or BGP hijacking (redirecting entire IP routes at the internet level).
- Decryption — interception alone isn't enough if the traffic is encrypted. Attackers use SSL stripping (downgrading HTTPS to HTTP before forwarding), presenting a forged certificate (if the user accepts it), or exploiting weak cipher suites to decrypt the traffic.
What a MitM attacker can do
- Read credentials — usernames, passwords, session tokens passing in unencrypted traffic
- Steal session cookies — log in as the victim without ever knowing the password
- Inject content — insert malicious scripts into web pages the victim loads
- Alter transactions — change a bank transfer destination, modify a form submission
- Eavesdrop silently — forward traffic unmodified after reading it, leaving no trace
The most common real-world scenario: public Wi-Fi
Rogue access points are the most practical MitM vector for opportunistic attackers. At a coffee shop, airport or hotel, an attacker sets up a hotspot with a convincing name — "Starbucks_WiFi" next to the real "Starbucks" network. Users connect and all their traffic flows through the attacker's device. If any of it is unencrypted HTTP, it's readable in plain text. If the attacker runs an SSL-stripping proxy, even some HTTPS sessions can be degraded.
How to defend against MitM attacks — for website owners
HTTPS everywhere (non-negotiable)
HTTPS encrypts traffic end-to-end between the browser and your server. An attacker who intercepts it sees encrypted ciphertext, not readable content. Use a valid certificate from a trusted CA — modern browsers flag expired or untrusted certificates prominently, and users should never proceed past those warnings.
HSTS (HTTP Strict Transport Security)
HSTS prevents SSL-stripping attacks by telling browsers never to connect over plain HTTP, even if redirected to it. With HSTS preloading, this protection applies even on a first visit to a new device. It's one of the most effective MitM mitigations a site can deploy.
DNSSEC protects against DNS-based MitM attacks — where an attacker poisons a resolver to serve a fake IP for your domain. It cryptographically signs your DNS records so resolvers can verify they haven't been tampered with. A user connecting to a DNSSEC-signed domain can't be quietly redirected to a fake server via DNS poisoning.
Certificate Transparency (CT) monitoring
Certificate Authorities log every certificate they issue to public CT logs. Monitoring these logs means you'll be alerted if a CA fraudulently issues a certificate for your domain — which is the prerequisite for a certificate-based MitM attack. Services like Facebook's Certificate Transparency monitoring or crt.sh let you check what certificates have been issued for your domain.
Strong cipher suites — disable TLS 1.0 and 1.1
Old TLS versions (1.0, 1.1) have known weaknesses exploited in attacks like BEAST and POODLE. Disable them on your server and enforce TLS 1.2 and 1.3 only. Modern hosting providers and CDNs do this by default, but older servers may not.
How to protect yourself as a user
- Never use public Wi-Fi for sensitive activity without a VPN
- Always check for HTTPS (padlock icon) before entering credentials
- Never click through certificate warnings — they mean the connection is not trusted
- Use a DNS resolver that supports DNSSEC validation (1.1.1.1, 8.8.8.8)
- Enable 2FA everywhere — a stolen session token is less valuable if the attacker can't use it to access other services
FAQ
Is HTTPS alone enough to prevent MitM attacks?
It prevents passive eavesdropping on the encrypted channel, but not all MitM vectors. SSL stripping can downgrade HTTP→HTTPS transitions unless HSTS is in place. A forged certificate from a compromised CA can decrypt HTTPS traffic if the user accepts it. HTTPS + HSTS + DNSSEC + CT monitoring together close the realistic attack surface.
Can a VPN prevent MitM attacks?
A VPN encrypts traffic from your device to the VPN server, protecting against local-network interception (rogue Wi-Fi). It doesn't protect against server-side attacks or compromised CAs. It also shifts trust to the VPN provider.
How common are MitM attacks?
Large-scale MitM attacks on HTTPS traffic are rare because the economics are hard. The more common threat is local-network interception of plain HTTP traffic or credential theft via phishing — which achieves the same result without the technical complexity. That's why "HTTPS everywhere" matters so much.