A man-in-the-middle (MITM) or adversary-in-the-middle attack places an attacker in the communication path between two parties that believe they are communicating directly. The attacker relays traffic and may read, delay, redirect, inject, or modify data while impersonating one or both sides.
NIST defines MITM as active wiretapping that intercepts and selectively modifies communications. Passive observation without relaying or modification is eavesdropping or packet sniffing; a fake login page reached normally is phishing. These threats can overlap but require different evidence.
How MITM access can happen
Rogue Wi-Fi or access point: the attacker controls a network with a convincing name or compromises the real access point.
ARP, DHCP, or routing manipulation: local or upstream traffic is redirected through an attacker-controlled system.
DNS manipulation: a hostname resolves to the wrong destination, which becomes dangerous when application authentication also fails.
Hostile proxy, VPN, malware, or certificate: local configuration or installed software can intentionally decrypt and relay traffic.
Compromised router or service infrastructure: an attacker changes the path or endpoint at a trusted layer.
What HTTPS protects
TLS encrypts traffic and authenticates the server name through certificate validation. A network observer can still see connection metadata, but should not be able to read or silently modify correctly protected content. Certificate warnings, a hostname mismatch, an untrusted root, or an unexpected downgrade are therefore important security signals.
The padlock proves an encrypted connection to the hostname shown; it does not prove that a look-alike hostname belongs to the intended company. An attacker may also succeed if malware installs a trusted root certificate or controls an enterprise inspection proxy.
Warning signs worth investigating
a certificate warning on a known service or a certificate issuer that differs unexpectedly;
new proxy, VPN, DNS, root-certificate, Wi-Fi, or device-management settings;
repeated redirects, HTTPS downgrade, altered downloads, or content that differs by network;
duplicate gateway addresses, unexpected ARP changes, rogue DHCP, or an unknown access point;
authentication prompts or session behavior that begin only on one network or device.
A slow connection, public Wi-Fi, or one logout does not prove MITM. Preserve the URL, certificate details, time, network, DNS answer, gateway information, and affected device before resetting everything.
Safe response
Stop sensitive activity and disconnect from the suspect network without accepting the certificate warning.
Reconnect through a trusted cellular or known network and reach the service independently.
If credentials or payment data were entered, revoke sessions and change exposed credentials from a known-clean device; contact the financial provider when necessary.
Remove only demonstrably unauthorized networks, proxies, VPNs, profiles, applications, and root certificates. Managed devices may have legitimate inspection controls.
In an organization, preserve packet, DNS, DHCP, ARP, proxy, certificate, identity, and endpoint evidence and investigate adjacent systems.
Prevention for users and organizations
keep browsers, operating systems, routers, and applications updated;
use HTTPS and never bypass certificate warnings for convenience;
disable automatic connection to unknown Wi-Fi and use authenticated, maintained networks;
use a trusted VPN on untrusted access networks, while remembering it protects only the path to the VPN and does not secure a compromised endpoint;
deploy HSTS, correct certificate validation, secure session handling, strong application authentication, and phishing-resistant MFA;
protect DNS, network administration, certificate authorities, proxies, and device-management accounts with least privilege and monitoring.
Reference: NIST: Man-in-the-middle attack.
MITM FAQ
Does a VPN prevent every MITM attack?
No. It protects traffic to the VPN when configured correctly, but the VPN provider, destination, endpoint, and stolen credentials remain in the trust model.
Is public Wi-Fi automatically malicious?
No. Treat it as untrusted and rely on authenticated encryption rather than assuming ownership or safety from the network name.