Why man-in-the-middle attacks work

A man-in-the-middle (MitM) attack happens when an intermediary position is inserted between your device and the site or service you think you are talking to. If the communication is not protected, an attacker may be able to observe traffic, modify it, or redirect you to an impersonated destination.

MitM risk is higher when you use untrusted networks (for example, public Wi‑Fi) or when connections are set up in a way that doesn’t strongly authenticate who you are communicating with. Even when websites use HTTPS, there are still scenarios where attackers try to interfere with how traffic is routed, how DNS names are resolved, or whether the secure channel is established correctly.

How a VPN helps (encryption and connection authentication)

A VPN (Virtual Private Network) helps primarily by creating a secure tunnel between your device and a VPN endpoint. When this tunnel is established, your device sends traffic through it in an encrypted form.

That matters for MitM because:

  • Confidentiality: If traffic is encrypted end-to-end between your device and the VPN endpoint, a network observer/intermediary on the path has less ability to read the content.
  • Integrity: Encryption plus protocol protections help detect or prevent undetected modification in transit.
  • Stronger “who you’re talking to” properties: Many VPN implementations also include mechanisms to authenticate the VPN endpoint (for example, via keys/certificates as part of the VPN handshake). When authentication is performed correctly, an attacker is less able to impersonate the VPN endpoint without being detected.

A practical way to think about it: instead of exposing your application traffic to the local network and route between your device and the internet, you carry it inside the VPN tunnel. The last-mile and onward traffic still depends on what happens after the tunnel exits, but the segment between your device and the VPN endpoint is protected.

Limits and important exceptions

A VPN is not a magic shield against every kind of compromise. The biggest limitations to keep in mind are:

1) The protection is only as good as the VPN’s trust and handshake

If the VPN connection cannot properly authenticate the endpoint, or if the client is misconfigured, then the tunnel may not provide the expected protections. Also, some network environments can interfere with VPN establishment (for example, by blocking VPN protocols). In such cases, you may be “connected to the VPN UI” but not actually using it for your traffic.

2) A VPN doesn’t automatically make endpoints trustworthy

Even with a VPN, you can still face risks if you connect to a malicious website or install malicious software. For example, if you visit a phishing page that uses deceptive content, the VPN can’t stop you from entering credentials into the wrong place.

3) Your browser/app still matters

MitM defenses for websites often rely on HTTPS and correct certificate validation. A VPN cannot replace those mechanisms. It can reduce certain network-path attacks, but it doesn’t eliminate the need for HTTPS verification, safe browsing, and cautious behavior.

4) DNS and “leaks” can change what you expose

If DNS queries or other traffic bypass the VPN tunnel (sometimes called leaks), the local network can still infer domains you are requesting, and attackers may attempt to interfere with name resolution. Not every setup has the same behavior, so it’s worth checking how DNS is handled on your device.

Practical checks to reduce MitM risk

You can’t fully “prove” a perfect security state, but you can verify several high-value signals that indicate whether you’re getting meaningful protection.

Verify the VPN is actually active

Confirm that the VPN client shows an active connection and that traffic is being routed through it. A common sanity test is to check whether your public IP or geolocation changes after the VPN connects (without assuming perfect accuracy), and to ensure the VPN stays connected during the test.

Check DNS behavior while on the VPN

Look for evidence that DNS resolution is happening through the VPN path rather than solely through your local network. On many systems, you can inspect network adapter settings or DNS servers to see whether they point to the expected VPN-related resolver. If you notice DNS servers that clearly belong to the local network while the VPN is active, investigate whether a leak is occurring.

Confirm HTTPS certificate validity in the browser

Open a few sites that use HTTPS and check that certificate warnings do not appear. If you see certificate errors while connected to the VPN, stop and investigate—certificate validation failures are a red flag for tampering, captive portals, or misconfiguration.

Use network tamper resistance signals

If you are on public Wi‑Fi with captive portals, make sure the VPN is established in a way that avoids traffic being redirected before the tunnel is up. Some portals can interfere with initial connections; if the VPN connects only after browsing has already occurred, you may expose some requests.

Keep expectations realistic

Even with these checks, security still depends on the entire chain: the VPN client, how endpoint authentication is handled, the integrity of your device, and whether you trust the destinations you visit. Treat a VPN as a strong mitigation for network-path MitM, not a substitute for HTTPS, malware hygiene, and careful user behavior.

A VPN is one layer in a broader set of defenses:

  • HTTPS/TLS: Protects site-to-browser communication when certificates validate correctly.
  • Certificate validation and trust stores: Determine whether clients accept or reject an endpoint’s identity.
  • DNS security and resolver choice: Can affect how domain names map to IP addresses.
  • Traffic routing and interception points: Determine where an attacker can observe or alter traffic.

If you’re trying to judge MitM risk for a specific scenario, focus on where you are exposed: the untrusted network segment, DNS resolution, and whether secure channels properly authenticate endpoints.