TL;DR: An attacker gets between two parties by controlling something on the path or by redirecting traffic to themselves: ARP spoofing on a local network, a rogue Wi-Fi access point, DNS spoofing or hijacking, a malicious proxy, or BGP route hijacking at internet scale. Once in position they can read and alter unprotected traffic. TLS stops them through three properties, and the decisive one is authentication: the server proves possession of a private key for a certificate the client trusts for that exact hostname. Encryption without authentication just means encrypting to the attacker. MITM against TLS succeeds only when validation is skipped or fooled: users clicking through warnings, apps that accept any certificate, downgrade to plain HTTP, or an attacker holding a certificate the client trusts.
How to approach it
Split the answer: how the attacker gets in the path (several techniques, at different layers), what they can do there, and which defence addresses each part. Then make the precise point that confidentiality and integrity follow from authentication, and list the ways authentication fails in practice.
A strong answer
The attacker has the same network position in both rows. Only the client's validation differs.
Client skips validation
Victim
connects to bank
Attacker
rogue Wi-Fi, ARP or DNS
Presents its own certificate
Real server
attacker relays traffic
Outcome, unsafe: Everything readable and changeable
Encryption to the attacker is not protection
Client validates the certificate
Victim
checks chain and hostname
Rejects untrusted or mismatched certificate
Attacker
same position
Has no key for a trusted certificate
Real server
unreached by the attack
Outcome, safe: Connection refused
Unless the attacker holds a certificate the client trusts
Getting into the path.
| Technique | Layer | How |
|---|---|---|
| ARP spoofing | Local network (layer 2) | Unsolicited ARP replies tell victims the attacker's MAC owns the gateway's IP |
| Rogue access point / evil twin | Wireless | An access point with a familiar network name that devices join |
| DHCP spoofing | Local network | A rogue DHCP server hands out the attacker as gateway or DNS |
| DNS spoofing or hijacking | Name resolution | Forged answers, a compromised resolver, or a hijacked domain |
| Malicious or compromised proxy | Application | Traffic configured, or forced, through it |
| BGP hijacking | Internet routing | Announcing someone else's IP prefixes so traffic is routed to the attacker |
Local-network defences include switch features such as dynamic ARP inspection and DHCP snooping, 802.1X network access control, and WPA3 or WPA2-Enterprise on wireless; RPKI route origin validation addresses BGP origin hijacks.
What the attacker can do in position. Read and modify plaintext protocols (HTTP, unencrypted email, legacy protocols), inject content, strip HTTPS upgrades, capture credentials, and redirect to phishing pages.
Why TLS stops them. TLS gives confidentiality, integrity and server authentication. The first two are only meaningful because of the third. The client checks that the certificate chains to a trusted root, is valid now, names the requested host, and that the server signed the handshake transcript with the matching private key. An attacker in the path can relay bytes but cannot produce that signature for a trusted certificate, so the handshake fails.
How MITM still succeeds.
- Users accept certificate warnings: HSTS makes warnings non-bypassable for listed sites.
- Downgrade to HTTP on the first request (SSL stripping): HSTS and preloading.
- Applications that disable validation (accept-all trust managers,
verify=False): code review and testing. - A certificate the client trusts: a mis-issuing CA (Certificate Transparency monitoring), a root the user or an MDM installed (enterprise interception, malware), which pinning addresses for apps that need it.
- Weak or no authentication in other protocols (unauthenticated Diffie-Hellman, legacy protocols).
Mutual authentication. Server authentication protects the client. Where the server must know the client (service-to-service traffic), mutual TLS adds a client certificate, which stops an attacker impersonating the client even if they are in the path.
What interviewers probe next
- "An attacker on café Wi-Fi does ARP spoofing. What can they see of a modern HTTPS session?" IP addresses, SNI unless ECH is used, DNS queries unless encrypted, timing and sizes; not content.
- "Why isn't encryption enough?" Without authentication the client might negotiate keys with the attacker, who then decrypts, reads and re-encrypts to the real server.
- "How would you detect ARP spoofing on a network you run?" Monitoring for changes in IP-to-MAC mappings, duplicate gateway MACs, and switch features that drop ARP replies not matching DHCP bindings.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
An attacker sits on the same coffee-shop Wi-Fi as a target who opens a company web app and an email client.
Start here
How can the attacker get on the path?
Which techniques work on a shared Wi-Fi?
ARP spoofing on the local network, running a rogue Wi-Fi access point, DNS spoofing or hijacking, a malicious proxy, or at internet scale BGP route hijacking. Each redirects traffic through the attacker.
Carry it forwardMany ways to get on path; assume attackers can.
Weak answerAssuming public Wi-Fi attackers are rare.
Constraint changes
What can they do once on path?
Which traffic is unencrypted?
Read and alter any unprotected traffic: plain HTTP, legacy mail protocols without TLS, and anything that ignores certificate errors.
Carry it forwardUnprotected traffic is fully exposed.
Weak answerThinking only passwords matter.
Constraint changes
Which TLS property stops them?
What if the client accepts any certificate?
Authentication. Encryption alone does not help if the client accepts the attacker's certificate. Proper certificate validation means the attacker cannot impersonate the server.
Carry it forwardServer authentication is the decisive defence.
Weak answerThinking encryption is the key property.
Constraint changes
What if the email client is configured to accept self-signed certificates?
Does the client verify the mail server's certificate?
Then the attacker can present their own certificate and read or modify mail, including password resets. Enforce certificate validation in managed client configurations and use modern authentication.
Carry it forwardClients must not accept untrusted certificates.
Weak answerAllowing exceptions for internal servers.
Constraint changes
What extra protections help on untrusted networks?
What if credentials are captured anyway?
HSTS on the web app, managed devices with always-on VPN or ZTNA for company traffic, phishing-resistant MFA so captured credentials are useless, and user guidance not to click through warnings.
Carry it forwardLayer HSTS, managed tunnels and strong MFA.
Weak answerRelying on users to avoid public Wi-Fi.
Now defend it
How would you defend the target?
Ensure every client validates certificates (no self-signed exceptions), deploy HSTS on the web app, route company traffic through always-on VPN or ZTNA on managed devices, use phishing-resistant MFA, and disable legacy unencrypted protocols.
How it's scored
Weak: "MITM is when someone intercepts traffic; HTTPS encrypts it."
Hire: Names several positioning techniques and explains that TLS certificate validation authenticates the server, defeating interception without a trusted certificate.
Strong Hire: Organises techniques by layer with local defences, states that integrity and confidentiality depend on authentication, lists the real failure modes (warnings, stripping, disabled validation, trusted rogue roots) with their controls, and mentions mutual TLS and visible metadata.
Common mistakes
- Treating encryption as sufficient without authentication.
- Forgetting the first-request HTTP downgrade.
- Assuming BGP and DNS attacks are out of scope because "TLS handles it", without noting what TLS needs to hold.
- Ignoring apps that disable certificate validation.