The One Sentence Definition
A man in the middle attack (MITM) is when an attacker secretly inserts themselves between you and the service you believe you are talking to directly, so that every piece of traffic in both directions actually passes through them first. They can read it, and often quietly alter it, while both you and the real service continue to believe the connection is direct and private.
The Basic Mechanism
Normally your data travels a simple path: you to the service. In a MITM attack it instead travels you to attacker to service, with the attacker relaying messages both ways so neither side notices anything unusual. To you, the connection looks completely normal. To the real service, requests appear to come from you, because they are simply being forwarded along by the attacker unchanged, or changed in ways you would not detect. Meanwhile the attacker sitting in the middle sees your passwords and messages as they pass through, and can inject their own changes into either direction.
Evil Twin WiFi
An attacker sets up a wireless access point broadcasting a name that mimics a legitimate one, something like "Airport_Free_WiFi" or a coffee shop's real network name with a slightly different capitalization. Connect to it and the attacker's equipment becomes your entire path to the internet: every unencrypted request you make passes directly through hardware they control. Our public WiFi security guide covers this scenario and how much of a realistic risk it still is today.
ARP and DNS Spoofing
On a shared local network, ARP spoofing tricks your device into believing the attacker's machine is the network's router, so your traffic routes through them before continuing on. DNS spoofing works similarly but at the naming layer, feeding your device a false address for a domain name so requests for a real site get silently redirected to infrastructure the attacker controls.
Fraudulent or Misissued Certificates
HTTPS relies on certificate authorities vouching that a given certificate really belongs to the domain it claims to represent. A compromised or careless certificate authority issuing a certificate for a domain to the wrong party, or an attacker with a way to install a rogue trusted root certificate on your specific device, can let a MITM proxy present what looks like a fully valid, padlocked connection.
SSL Stripping and Real Time Phishing Proxies
SSL stripping quietly downgrades what should be an HTTPS connection to plain HTTP before you notice, removing the encryption a user would otherwise rely on. A more modern and more dangerous variant is the real time phishing proxy: a fake login page that is not just a static copy but an active relay, forwarding your credentials to the real site instantly and returning the real site's response back to you, all while capturing everything that passes through in both directions.
Why Modern HTTPS Makes Classic MITM Much Harder
The reason MITM attacks are far less devastating today than they were in the era of open, unencrypted WiFi is HTTPS becoming close to universal. When you connect over HTTPS, your browser cryptographically verifies the site's certificate against a trusted chain and encrypts the entire connection, so an attacker sitting in the middle sees only scrambled ciphertext and cannot convincingly impersonate the real site without possessing a certificate that validates for that exact domain (our HTTPS and TLS explainer covers the certificate chain in detail). Certificate pinning, used by some mobile apps, raises the bar further by hardcoding which specific certificate or authority an app will accept, closing off even a technically valid but unexpected certificate from a different authority. This is exactly why a browser's "Not Secure" warning is not decoration: without HTTPS, a MITM sitting anywhere on the path reads every request in plain, unencrypted text.
The old style MITM attack, quietly sniffing passwords off open WiFi in plaintext, mostly died once the web moved to HTTPS by default. The attack did not disappear. It moved: toward tricking you into connecting to a fake network in the first place, or toward a fraudulent site that becomes a legitimate seeming endpoint you should never have trusted to begin with.
Why Certificate Pinning and HTTPS Do Not Make MITM Impossible
None of these defenses make a MITM attack theoretically impossible, only substantially harder and far less common than they used to be. A misissued certificate from a compromised authority, a user manually clicking through a certificate warning, malware that installs a trusted root certificate on the device itself, or simply being steered to a different, fraudulent domain that has its own perfectly valid certificate, all remain realistic paths around HTTPS's protections. HTTPS proves your connection to a domain is encrypted and that the domain's certificate is valid. It does not, and cannot, prove that the domain itself is the one you actually meant to visit.
The Uncomfortable Part: This Can Defeat Some 2FA
A real time phishing proxy is itself a form of man in the middle attack, and it is specifically capable of defeating SMS codes and standard TOTP based two factor authentication. The mechanism is not that it breaks the code mathematically: it relays your password and your freshly typed, still valid code straight through to the real site the instant you enter them, then simply steals the authenticated session that comes back. Your six digit code was completely legitimate. The attacker just used it a few seconds before its thirty second window expired, on your behalf, without you knowing.
This exact weakness is why phishing resistant authentication methods exist at all. Passkeys and hardware security keys are cryptographically bound to the real domain during registration, and they simply refuse to produce a valid response for any other origin, including a convincing fake one. There is nothing for a relay style MITM to steal, because the device checks the actual domain before it will respond at all (our FIDO2 and WebAuthn explainer covers exactly why this binding works).
Practical Defenses
- Insist on HTTPS and actually look at the domain, not just whether a padlock icon is present. Never enter credentials on a page flagged "Not Secure."
- Be deliberately wary of unfamiliar networks. Verify a WiFi network's name with staff before connecting where possible, and prefer your own phone's cellular hotspot over public WiFi for anything sensitive.
- Never click through a certificate warning. "Your connection is not private" can be exactly what an active MITM attempt looks like from the browser's perspective; treat it as a stop sign, not a suggestion.
- Move important accounts to phishing resistant 2FA such as passkeys or hardware keys, so that even a successful real time relay attack captures nothing usable.
- Keep your device and browser updated, since a meaningful share of practical MITM techniques exploit specific, already patched vulnerabilities rather than defeating the cryptography itself.
Frequently Asked Questions
Can a man in the middle attack still happen if I am using HTTPS?
The classic version, an attacker passively reading your plaintext traffic, no: HTTPS encrypts the connection and authenticates the domain. But you can still be steered toward a fraudulent site that itself has a perfectly valid HTTPS certificate and functions as a MITM relay. HTTPS proves the connection to that specific domain is encrypted. It does not prove the domain is the one you actually intended to reach, so checking the address bar carefully still matters.
Does using a VPN protect against man in the middle attacks?
Partially. A VPN encrypts your traffic between your device and the VPN provider's server, which defeats a local network based MITM such as evil twin WiFi or ARP spoofing on that specific network. It does nothing against a real time phishing proxy, since you would still be typing your credentials directly into the fake site regardless of whether a VPN is running, and it does nothing against malware already present on your device.
How would I actually know if I was being targeted by a MITM attack right now?
Often you would not notice at all, which is precisely what makes this attack dangerous. Warning signs worth taking seriously include unexpected certificate errors, a "Not Secure" label appearing where you would not expect one, or a login page sitting at a domain that is subtly wrong. Phishing resistant 2FA removes the need to spot it in the moment, since the attack simply cannot succeed against it regardless of how convincing the fake page looks.
Is public WiFi a guaranteed man in the middle risk today?
Much less than it used to be, largely thanks to HTTPS becoming the default across almost the entire web. The realistic modern risks on public WiFi are fake access points and fraudulent login pages rather than passive traffic sniffing, which HTTPS has largely neutralized. Our public WiFi security guide separates the genuine current risks from outdated fears that no longer match how the web actually works.
Why can't two factor authentication always stop a man in the middle attack?
Because a real time relay proxy forwards your code within its valid time window rather than trying to crack or guess it. The code itself is never broken, it is simply forwarded on your behalf a few seconds before it expires. Only authentication that is cryptographically bound to the true origin domain, meaning passkeys and hardware security keys, resists this specific attack, because the device checks the actual domain and refuses to respond to anything else, no matter how convincing the imitation looks.
