Man-in-the-Middle Attacks: Risks and Practical Protection

A man-in-the-middle attack, also called an on-path attack, places an attacker between communicating parties so they can observe, relay or alter traffic. Being on the network path does not automatically let someone read correctly authenticated, encrypted HTTPS content. The details of the connection and its trust checks matter.

For example, a hostile access point may observe traffic metadata, interfere with connectivity or target unencrypted requests. That is different from silently decrypting every banking session on the Wi-Fi network. Avoid both extremes: assuming public Wi-Fi is harmless and assuming encryption offers no protection.

Separate redirection from decryption

Local-network manipulation or poisoned name resolution may send a connection toward the wrong system. A correctly validating TLS client should reject a server that cannot authenticate for the requested hostname. A DNS change alone does not bypass that check. Trust-store compromise, broken certificate validation or persuading the user to ignore a warning changes the situation.

HTTPS protects a connection to a hostname; it does not prove that a lookalike domain belongs to the organization you intended to visit. A phishing website can have a valid certificate for its own name. Check the address, not just whether the browser shows an encrypted connection. MDN's TLS guide explains authentication and transport protection.

What a reader can do immediately

• Do not bypass certificate warnings to sign in. Verify the address and investigate using another trusted connection.
• Do not install a certificate or “Wi-Fi helper” profile from an unexpected captive portal.
• Keep browsers and operating systems updated, and use a saved bookmark or your own typed address for sensitive accounts.
• Use phishing-resistant authentication where the service offers it, such as FIDO2/WebAuthn security keys or passkeys. Protect recovery methods too.

A one-time code is not equivalent to phishing-resistant authentication: a deceptive sign-in flow may relay it while it is still valid. CISA's phishing-resistant MFA guidance explains the stronger approach. No authentication method removes the need to protect the device and its active sessions.

Where a VPN helps, and where it does not

A properly configured VPN encrypts traffic through a tunnel to its endpoint, reducing what the local network can observe or modify inside that tunnel. It also moves trust toward the VPN operator and its infrastructure. It does not make a fake website genuine, fix a compromised browser or replace HTTPS between the client and the destination service.

Ask which traffic the VPN actually carries: split tunneling and DNS configuration can affect the answer. On a managed work device, follow the organization's VPN and certificate policies instead of installing an unfamiliar consumer client to work around a warning. The NCSC VPN guidance discusses tunnel scope and organizational deployment.

Controls for a site or application owner

Validate certificates and hostnames in outbound clients; do not ship a temporary “skip verification” workaround. Serve sensitive pages over HTTPS, maintain certificate renewal and eliminate mixed-content dependencies. Introduce HSTS only after confirming that the intended hostnames can reliably support HTTPS; broad subdomain policies need planning. The OWASP TLS guide provides deployment checks.

Review proxy trust separately. An application should not accept arbitrary forwarded headers from any Internet client just because it normally sits behind a reverse proxy. Document where TLS terminates and how the next connection is protected. Transport controls do not repair application authorization defects.

If something already looked wrong

A certificate warning is a reason to stop, not proof by itself of an attack; expired certificates, a wrong clock or a legitimate managed inspection system can also be involved. Record the hostname, warning and time without sharing credentials. Ask the service owner or your IT team to investigate.

If you entered credentials into a suspected interception or phishing flow, switch to a trusted device and connection, change the affected password through the official service, revoke active sessions where available and review recovery settings. For a work account, report the event promptly so the team can check logs and contain related access.