How does mutual authentication defeat a MitM attack? Give examples from TLS and SSH.

Question

Accepted Answer

Both endpoints cryptographically verify each other before exchanging data. The attacker can't impersonate either side without the corresponding private key, so the handshake fails.
TLS server authentication:
1. Client → "I want to talk to bank.com"
2. Bank's server presents: certificate signed by trusted CA
3. Client checks:
   - Is the certificate signed by a CA in my trust store?
   - Does the cert's domain match "bank.com"?
   - Is it within validity dates?
   - Is it not on a revocation list?
4. Pass all → trust + derive session key
   Fail any → big red warning, abort

If a MitM tries to impersonate bank.com, they need either:

A valid cert for bank.com (requires compromising a CA — extremely rare)
A self-signed cert (browser warning blocks this)

SSH host fingerprint pinning:
First connection:
The authenticity of host 'server.com' can't be established.
ED25519 key fingerprint is SHA256:Z4...8q.
Are you sure you want to continue connecting (yes/no)?

After accepting, the fingerprint is stored in ~/.ssh/known_hosts. Future connections compare — if the fingerprint differs, SSH refuses to connect:
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Certificate pinning (mobile apps):
Apps embed the expected cert/public key. Even if a CA is compromised, a forged cert won't match the pinned one → connection fails.
The catch — TOFU (Trust On First Use):
SSH has a chicken-and-egg problem: how do you know the first fingerprint is genuine? If a MitM is active when you first connect, you accept their fingerprint as truth. Some orgs distribute fingerprints out-of-band to avoid this.
Tip: When you see a browser cert warning ("not secure"), DON'T click through on banking/work/email sites — that's an active MitM signal. Switch networks (off public WiFi) and try again.