What is a man-in-the-middle attack

A man-in-the-middle (MITM) attack is when an attacker positions themselves between two parties communicating over a network, reading or modifying traffic in both directions without either party realising they're not talking to each other directly.

Picture: you connect to your bank's website. An attacker has compromised the network in between. They intercept your connection, present their own certificate (pretending to be the bank), and forward your traffic to the real bank — collecting passwords or modifying transactions on the way through.

If TLS works correctly, the attacker's certificate fails validation and your browser warns you. If TLS works incorrectly, you don't notice.

Where MITM attacks happen

A few scenarios where this is realistic:

• Public Wi-Fi. Hotel networks, café Wi-Fi, airport networks. The attacker may be the network operator or anyone else on the same network. See VPN for public Wi-Fi for why this matters.
• Compromised routers. Home routers with default passwords, ISP-supplied routers with backdoors. The attacker controls your gateway; everything passes through them.
• State-level adversaries. Some countries operate MITM at scale via fake certificate authorities issued from compelled CAs. Less common since Certificate Transparency made misissuance visible, but not gone.
• Compromised CAs. A CA's intermediate key gets stolen; attackers issue valid-looking certs for arbitrary domains. Has happened (DigiNotar, Comodo). Browsers eventually distrust the affected CA.

How TLS defends against MITM

TLS verifies the server's identity through certificates signed by trusted CAs. When you connect, the server presents its certificate. Your browser checks: is this certificate signed by a CA I trust? Does the hostname match? Has it been revoked?

If any check fails, the browser refuses to connect or warns you. If everything passes, the encrypted session continues.

For this to defend against MITM, three things have to hold:

1. The CA system has to be uncompromised. A rogue CA can issue valid certs for any domain.
2. Your trust store has to be clean. If an attacker installed their CA cert on your machine (corporate networks, malware), they can issue valid certs you'll trust.
3. You have to honour the warning. Browsers warn on cert errors; users click through anyway.

Certificate pinning: stronger defence

For high-value connections, regular CA validation isn't enough. Certificate pinning hard-codes which specific certificate (or CA) a client should expect. If the certificate doesn't match the pin, the connection fails — even if it's signed by a "trusted" CA.

Fexyn pins its own intermediate CA in the desktop client. The client refuses any VPN connection where the server's cert isn't signed by that intermediate. A compromised public CA can't be used to MITM Fexyn traffic — the client doesn't trust public CAs for VPN connections, only Fexyn's internal PKI.

This is one of the reasons MITM attacks against Fexyn require compromising Fexyn's signing infrastructure specifically, not just any random CA on the internet.

What a VPN does and doesn't do

A VPN makes MITM on the underlying network mostly impossible. The tunnel is encrypted between your device and the VPN server; nobody on the path between can MITM what's inside.

A VPN doesn't protect against MITM at the destination — once your traffic exits the VPN server and goes to its real target, normal TLS is the only defence. And a VPN doesn't protect against MITM at the origin — malware on your device can MITM you before traffic enters the tunnel.

Read more in the security overview and the public Wi-Fi guide.

The most documented state-level MITM attempt in the VPN context is Kazakhstan's 2015 and 2019 push of the Qaznet root CA, which would have enabled wholesale HTTPS interception had the major browser vendors not blocklisted it. The VPN for Kazakhstan guide covers the threat model and which protocol is structurally immune to it.

Try Fexyn free for 7 days.