What Is a Man-in-the-Middle (MITM) Attack?

The plain-English guide to one of the oldest tricks in networking, still working in 2026. How someone intercepts communications and how to defend yourself.

What Is a Man-in-the-Middle (MITM) Attack?

The plain-English guide to one of the oldest tricks in networking, still working in 2026. How someone can quietly insert themselves into a conversation you think is private, the specific techniques that make it possible, and the handful of habits that shut the door on almost all of them.

Why this old attack still works in 2026

The idea behind a MITM attack predates the internet by a long way, intercepting mail, tapping phone lines, and forging diplomatic cables are all the same trick in earlier technology. What keeps it relevant in modern networking is that a lot of the infrastructure connecting your device to the internet was built for functionality first and authentication second.

Wi-Fi routers broadcast their presence to anyone in range. DNS, by default, has no built-in way to prove a response actually came from a legitimate resolver. Local networks trust address-resolution messages from any device on them, by design, because verifying every one would have been impractical when these protocols were designed decades ago.

None of that was a mistake exactly, these protocols needed to be fast, simple, and universally compatible, and strong authentication at every layer would have made 1980s and 1990s networking hardware unworkable. But it left structural gaps that a nearby, motivated attacker can exploit, and those gaps haven’t disappeared just because the web layered strong encryption on top decades later.

HTTPS fixed an enormous amount. It did not fix everything sitting underneath it.

A simple analogy: the mail carrier who reads your letters

Imagine you’re writing a letter to a friend and handing it to what you believe is your regular mail carrier. In a man-in-the-middle attack, someone has quietly taken your regular carrier’s place, maybe they’re wearing a convincing uniform, maybe they’ve simply shown up at your mailbox first. You hand over the letter as normal. They open it, read it, perhaps copy down anything interesting, reseal it, and deliver it onward.

Your friend gets a reply back through the same impostor carrier, who reads that too before handing it to you.

Neither you nor your friend notices anything unusual, because the letters still arrive, still look normal, and the conversation continues exactly as expected. The only thing that changed is who’s actually handling the mail in between, and that’s precisely what makes this attack dangerous. It doesn’t look like an attack. It looks like nothing happened at all.

Modern network encryption is the equivalent of sealing that letter inside a tamper-evident envelope that only your actual friend has the key to open, and that shows unmistakable signs of interference if anyone tries to open it along the way.

A man-in-the-middle attack, at its core, is always some version of an attacker trying to get their hands on your letters before that seal makes tampering pointless, either by intercepting them before the envelope goes on, or by tricking you into using a broken envelope in the first place.

What a man-in-the-middle attack actually is

A man-in-the-middle attack is any situation where a third party secretly positions itself between two communicating parties, relaying (and potentially reading or altering) traffic between them, while both original parties believe they’re communicating directly with each other.

Stripped of any specific technique, the definition is simple: an attacker sits between two parties who believe they’re talking directly to each other, and relays traffic between them while secretly observing or modifying it. Both the “man” and the “middle” in the name are literal, a third party has inserted itself into the middle of a two-party exchange.

What makes this category broader than most people assume is that it isn’t tied to any single technique. It’s a description of a position an attacker achieves, not a specific tool or exploit.

An attacker can get into that position through a fake Wi-Fi hotspot, through manipulating how your device resolves domain names, through exploiting how devices on a local network trust each other’s identity claims, or even, at a much larger scale, through manipulating how traffic gets routed across the internet backbone itself.

Later sections in this guide walk through each of these individually, because the specific mechanism matters enormously for understanding both the risk and the fix.

The three things every MITM attack needs

It helps to break the attack down into its constituent requirements, because doing so makes the defenses much more intuitive.

• Positioning: The attacker needs your traffic, or the other party’s traffic, to physically or logically pass through them. This might mean being on the same Wi-Fi network as you, controlling a router along your traffic’s path, or manipulating routing tables somewhere further upstream.

• Impersonation: Once positioned, the attacker needs each side to believe they’re talking to the legitimate party. This is where certificates, domain names, and network identities come in, an attacker either forges a convincing fake identity or exploits a system that doesn’t verify identity strongly enough to catch the forgery.

• Interception or tampering: With both of the above in place, the attacker can now passively read traffic (the more common goal, credentials, session cookies, personal data) or actively alter it in transit (injecting malicious content, redirecting payments, modifying downloaded files).

Every specific MITM technique covered in this guide is really just a different way of satisfying these same three requirements. Understanding that pattern is more useful than memorizing any single technique, because new variations keep appearing that are really just new answers to the same three-part problem.

How attackers actually get in the middle

MITM attacks fall into a handful of well-documented categories: fake Wi-Fi hotspots (evil twins), local-network identity spoofing (ARP spoofing), domain-resolution manipulation (DNS spoofing), certificate and encryption downgrade attacks (SSL stripping), and large-scale internet routing manipulation (BGP hijacking). Each achieves the same basic goal through a different weak point.

The rest of this guide walks through the specific techniques one at a time, roughly ordered from the most common and accessible (something a moderately skilled attacker can do at a coffee shop with cheap hardware) to the most sophisticated (something that typically requires access to internet infrastructure itself).

Knowing the names matters less than understanding the shape of each one, but knowing the names does help you make sense of security news and vendor advisories when they come up.

The evil twin: fake Wi-Fi hotspots explained

This is the most accessible MITM technique in this guide, requiring nothing more exotic than inexpensive, widely available hardware and a public location where people expect free Wi-Fi. An attacker sets up a wireless access point broadcasting a network name identical or very similar to a legitimate one, “Airport_Free_WiFi,” “Starbucks_Guest,” a hotel’s actual network name copied exactly, often with a stronger signal than the real network, so nearby devices are more likely to connect to the impostor automatically.

Once a device connects, the attacker’s equipment functions as that device’s gateway to the internet. That means every unencrypted request, every DNS lookup, and every piece of metadata about which sites are being visited flows directly through hardware the attacker controls.

Some evil-twin setups go further, presenting a fake captive-portal login page designed to harvest credentials directly. This is especially effective against travelers who expect to enter hotel or flight confirmation details to get online.

The defense here is mostly about habits rather than technology: verifying a network name with staff before connecting, treating any “free Wi-Fi requires login with your email/password” prompt with suspicion, and, most reliably, running a VPN so that even a successful evil-twin connection only gets the attacker an encrypted stream they can’t read.

ARP spoofing: hijacking traffic on your own network

Address Resolution Protocol (ARP) spoofing exploits the fact that devices on a local network trust unauthenticated broadcast messages claiming “this IP address belongs to this hardware address.” An attacker already on the same network sends forged ARP messages claiming to be the router, redirecting nearby devices’ traffic through their own machine.

This technique targets a specific, decades-old weak point in how local networks function. Every device on a network needs to translate IP addresses into physical hardware addresses (MAC addresses) to actually deliver traffic, and it does this using the Address Resolution Protocol (ARP), a simple broadcast-based system with essentially no built-in authentication.

Any device on the network can claim, via an ARP message, “I am the hardware behind this IP address,” and other devices will generally believe it without verification.

An attacker who has already gained access to a local network, a shared office network, a poorly secured home network, a public network without client isolation, can send forged ARP messages claiming to be the router. Nearby devices update their internal tables accordingly and start sending their internet-bound traffic to the attacker’s machine instead of the actual router.

The router then typically forwards the traffic onward (to avoid an obvious outage that would tip off the target) while quietly copying it along the way.

This is precisely the kind of attack that a well-built VPN’s network architecture is designed to make irrelevant, a properly isolated tunnel means that even if an attacker successfully spoofs the local network’s traffic flow, everything they capture is encrypted at a layer their local-network trickery can’t touch.

DNS spoofing: sending you to the wrong address entirely

Every website visit typically starts with a DNS lookup translating a human-readable domain into a numeric IP address. By default, that lookup happens over an old, unauthenticated protocol.

An attacker capable of intercepting or answering that lookup, whether by controlling the local network, poisoning a shared DNS cache, or operating a malicious resolver you’ve been redirected to use, can simply lie about the answer. They send your device to a server they control instead of the real one, all while the address bar continues to show the domain name you actually typed.

This is a particularly effective MITM technique specifically because it operates before your browser has connected to anything. That means the visual cues people are trained to look for, the padlock icon, the URL itself, can appear entirely normal right up until the point where the fake site’s own certificate (or lack of one) becomes the giveaway.

A well-executed DNS spoofing attack combined with a convincing fake login page has been behind a meaningful share of real-world credential theft over the years.

Encrypted DNS, DNS over HTTPS (DoH) or DNS over TLS (DoT), directly addresses this by making the lookup itself unreadable and unforgeable to anyone sitting on the local network, closing off this specific technique regardless of how compromised the local network otherwise is.

SSL stripping and forged certificates

Forged or maliciously issued certificates achieve a similar result by convincing a device to trust an attacker-controlled encrypted connection outright.

This category targets HTTPS itself, rather than the layers underneath it, and represents the more sophisticated end of the MITM technique spectrum.

SSL stripping exploits the fact that many web sessions technically begin with a plain, unencrypted HTTP request that then redirects to HTTPS. That brief window is exactly what an attacker positioned in the middle can exploit by intercepting that initial request and serving the victim a plain-HTTP version of the site indefinitely, while separately maintaining a proper HTTPS connection to the real site on the victim’s behalf.

The victim sees a functioning website. They may or may not notice the missing padlock icon, depending on how attentive they’re being and how the attacker has disguised the page.

Modern browsers and a security mechanism called HSTS (HTTP Strict Transport Security) have significantly reduced this attack’s effectiveness by telling browsers to refuse plain-HTTP connections to sites that have opted in. But not every site has opted in, and not every browsing scenario benefits from the protection.

Forged or maliciously trusted certificates take a more direct approach: if an attacker can get a device to trust a fraudulent certificate, through a compromised certificate authority, a corporate or malicious root certificate installed on the device, or a user clicking through a security warning, they can present themselves as the legitimate site with a fully valid-looking HTTPS connection, encryption and all.

They then quietly relay (and read) everything in between. This is precisely why browser certificate warnings exist, and precisely why clicking through them without understanding what they mean is one of the more dangerous habits in everyday browsing.

BGP hijacking: MITM at internet scale

Border Gateway Protocol (BGP) hijacking involves manipulating the routing announcements that tell the internet’s backbone how to reach a given block of IP addresses. It redirects traffic destined for a legitimate service through infrastructure the attacker controls, a MITM attack executed at the level of internet infrastructure rather than a single local network.

This is the least common technique in this guide for an individual to encounter directly, but it’s worth understanding because of its scale and because it’s periodically responsible for major, headline-making incidents.

The internet’s backbone routers rely on BGP (Border Gateway Protocol) to figure out how to reach any given block of IP addresses. BGP was designed decades ago around a basic assumption of trust between network operators, an assumption that doesn’t hold up against a network operator, or someone impersonating one, who deliberately announces false routing information.

A successful BGP hijack can redirect a significant volume of traffic destined for a specific service, a bank, a cryptocurrency exchange, a major platform, through infrastructure controlled by the attacker. The attacker can then intercept, analyze, or in some documented cases actively manipulate that traffic before releasing it onward, all while affected users typically see no obvious sign anything has changed.

Because this technique operates at the routing-infrastructure level rather than targeting individual users, it’s largely outside what any individual’s personal security habits can defend against. The defense here lives with network operators implementing route validation standards like RPKI (Resource Public Key Infrastructure), not with end-user behavior.

What it does mean for you personally: strong end-to-end encryption (HTTPS, a VPN tunnel) still protects the content of your traffic even if it’s briefly routed somewhere unexpected at the infrastructure level.

Real incidents worth knowing about

2011

DigiNotar, a Dutch certificate authority, is compromised. Attackers issue fraudulent certificates for major domains including Google, later linked to interception of Iranian users’ Gmail traffic through forged, trusted certificates.

2013

Public disclosures around bulk network interception programs bring mainstream attention to the scale at which traffic interception can occur at the infrastructure level, accelerating the industry’s push toward HTTPS-by-default.

2015

Superfish, adware pre-installed on some consumer laptops, is found to install a root certificate that lets it, and potentially any attacker who reverse-engineered its private key, intercept and decrypt HTTPS traffic on affected machines. It was a textbook MITM vulnerability shipped by default.

2017

A widely reported BGP hijacking incident briefly reroutes traffic for a range of prominent internet services through unexpected infrastructure, renewing industry attention on BGP route validation.

2018

Major browsers begin visually flagging plain-HTTP sites as “Not Secure”, a direct response to how effective SSL-stripping-style attacks had been against users who never noticed the missing padlock.

2020s

Evil-twin Wi-Fi attacks at conferences, airports, and hotels continue to be documented by security researchers as a persistent, low-cost, high-yield technique, particularly against travelers using unfamiliar networks.

If there’s a single takeaway from this timeline, it’s that MITM attacks haven’t gone away as encryption has improved, they’ve moved to whichever layer still has the weakest verification. Over time, that shifted from raw traffic interception toward certificate trust and routing infrastructure.

How HTTPS actually defeats most of this

It’s worth pausing to give HTTPS real credit here, because a lot of MITM-focused content skips past just how effective it actually is when working as intended.

TLS, the encryption protocol underneath HTTPS, was explicitly engineered with the man-in-the-middle threat model in mind, not as an afterthought, but as the central problem it exists to solve.

Two mechanisms do the heavy lifting.

Encryption means that even if an attacker successfully positions themselves in the middle, through an evil twin, ARP spoofing, or a compromised router, the traffic they intercept is unreadable ciphertext. It’s useless without the private key that only the legitimate server holds.

Certificate-based identity verification means that before any of that encryption even begins, your browser checks a cryptographically signed certificate proving the server actually is who it claims to be. It’s issued by a certificate authority your device already trusts, making it extremely difficult for an attacker to simply claim to be a legitimate site without either compromising that trust chain or triggering a very visible browser warning.

Put together, this is why plain ARP spoofing or an evil-twin Wi-Fi network, on their own, mostly fail against a properly HTTPS-secured site today: the attacker can redirect your traffic through their equipment, but they can’t read it, and they can’t convincingly impersonate the destination without the browser noticing something is wrong.

Where HTTPS still leaves a gap

HTTPS doesn’t help if a user clicks through a certificate warning, if a site never migrated to HTTPS in the first place, if a device has been tricked into trusting a fraudulent root certificate, or if the attack targets the layer underneath HTTPS entirely, like DNS or raw network metadata, both of which remain visible even on a fully HTTPS-protected connection.

Despite everything HTTPS does well, several real gaps remain, and being honest about them is more useful than pretending the problem is fully solved.

Certificate warnings that get clicked through. The entire security model depends on users treating a certificate warning as a stop sign rather than an inconvenience. In practice, a meaningful share of users click through them, especially on unfamiliar public Wi-Fi where warnings can feel like routine friction rather than a genuine red flag.

Sites that never adopted HTTPS. A shrinking but nonzero share of the web, along with plenty of older embedded devices and internal corporate tools, still serves plain HTTP. That offers zero protection against interception for anyone using them.

Fraudulently trusted root certificates. If an attacker, or pre-installed adware, as in the Superfish incident, has gotten a device to trust a certificate it shouldn’t, HTTPS’s identity verification is compromised from the inside. The encrypted padlock icon can appear fully legitimate while an attacker reads everything.

Everything DNS and metadata. HTTPS protects content, not the domain lookup or network-level metadata surrounding a connection. That means DNS spoofing can still redirect a user before HTTPS ever gets involved. Even on a fully protected connection, the destination domain, timing, and volume of traffic often remain visible to anyone positioned on the network.

This is exactly why the practical advice in this guide layers multiple defenses rather than treating HTTPS as a single complete solution.

Five myths about man-in-the-middle attacks

“MITM attacks only happen on public Wi-Fi.”

Public Wi-Fi is the easiest and most common setting, but ARP spoofing works on any local network including home and office networks. BGP hijacking operates at internet-infrastructure scale entirely independent of which network you personally connect to.

“HTTPS means I’m completely safe from man-in-the-middle attacks.”

Mostly true, but not entirely. Certificate warnings clicked through, sites that never adopted HTTPS, and fraudulently trusted root certificates all remain real, if less common, avenues around it. HTTPS was never designed to hide DNS lookups or network metadata in the first place.

“A VPN completely eliminates any MITM risk.”

A VPN closes most of the network-positioning techniques covered in this guide, an evil twin or ARP spoofing attacker only captures encrypted traffic they can’t read once it’s inside a VPN tunnel. It doesn’t fix a fraudulently trusted certificate already installed on your device. It also shifts some trust to the VPN provider itself, which is exactly why a VPN’s own security practices matter.

“Only technical experts can pull off a MITM attack.”

Evil-twin hotspots and basic ARP spoofing can be executed with inexpensive, widely available hardware and freely available tools. That requires far less technical sophistication than most people assume, which is part of why the attack remains common rather than a fading relic of less-secure networking eras.

“If my connection still works normally, nothing suspicious is happening.”

This is precisely the point of a well-executed MITM attack. A passive attacker who’s only reading traffic, not altering it, leaves the connection functioning exactly as expected. The absence of visible disruption is not evidence of safety; it’s often the goal.

How to actually protect yourself

Here’s the practical, ordered list.

What actually closes the gap

• Never click through a certificate warning without understanding it. This single habit change closes off both SSL-stripping-adjacent tricks and forged-certificate attacks more reliably than almost anything else on this list.

• Verify a public Wi-Fi network’s exact name with staff before connecting, and be suspicious of any network prompting for a login with real credentials rather than a simple click-to-accept portal.

• Use encrypted DNS (DoH or DoT), which closes the DNS-spoofing gap regardless of how compromised the local network otherwise is.

• Run a VPN on any network you don’t personally control, coffee shops, hotels, airports, conference Wi-Fi. This turns a successful evil-twin or ARP-spoofing capture into useless encrypted noise.

• Keep browsers and operating systems updated, since HSTS enforcement, certificate-trust lists, and other MITM-relevant protections improve continuously and rely on running current software.

• Check for duplicate network names when connecting somewhere new, two networks with the identical name in the same location is a specific, recognizable evil-twin pattern.

• Avoid installing unnecessary root certificates, and periodically review which ones are trusted on devices where that’s feasible, particularly after installing free or ad-supported software.

How OllaVPN closes the network-level gap

We built OllaVPN around the idea that the network you happen to be connected to shouldn’t determine how exposed your traffic is. For the specific MITM techniques covered in this guide, here’s what that means in practice.

• Every connection runs through an encrypted tunnel by default, so an evil-twin hotspot or ARP-spoofing attacker on the local network only ever captures unreadable ciphertext, regardless of how convincingly they’ve positioned themselves.

• DNS is handled entirely inside the tunnel, closing the DNS-spoofing gap described above without requiring any separate configuration.

• A post-quantum-ready hybrid handshake on every connection, protecting the tunnel’s own key exchange against future decryption, see our pillar guide on post-quantum cryptography for the full picture.

• An always-on kill switch ensures that if the tunnel ever drops on an untrusted network, traffic stops rather than silently falling back to an exposed, unencrypted connection.

• Free for life, on every plan, the protection that matters most on public Wi-Fi shouldn’t be reserved for people willing to pay for it first.