A man-in-the-middle attack puts an attacker between two communicating parties so they can intercept or alter the data. The defence is to make intercepted traffic useless and tampering detectable: use TLS 1.3 everywhere, enforce HTTPS with HSTS, validate certificates properly, and verify what you download.
What does NIST say a man-in-the-middle attack is?
NIST's glossary gives two related definitions. One, from SP 1800-21B, describes an attacker positioned between two communicating parties to intercept and alter data. The authentication version puts the attacker between claimant and verifier, between registrant and credential service provider during enrollment, or between subscriber and provider during authenticator binding.
The second form is a reminder that the attack is not only about browsing. Account enrollment and device pairing are exposed too.
How does an attacker get into the middle?
Position comes from the network or from the endpoint. A shared Wi-Fi hotspot, a rogue access point, a poisoned local network, a hostile proxy or a compromised router can all sit on the path. On the endpoint, a root certificate installed by malware lets software read encrypted traffic as the user.
The attacker then tries one of three things: read the traffic, change it, or force both sides to use weaker protection.
What does TLS 1.3 do about it?
RFC 8446 specifies TLS 1.3. Its handshake authenticates the server, usually through a certificate, and establishes keys so the session is encrypted and tamper evident. It also carries downgrade protection. A TLS 1.3 server that negotiates TLS 1.2 or lower must set the last 8 bytes of its Random value to a special value, so a client that wanted 1.3 can notice that someone forced an older version.
Encryption alone is not enough without certificate validation. A client that ignores certificate errors accepts the attacker's certificate and the encryption ends at the attacker. This shows up in code more than people expect, as a flag that disables verification "just for testing" and ships.
What does HSTS add?
The first request to a site is often plain HTTP, and an attacker can answer it. RFC 6797, HTTP Strict Transport Security, lets a site send a header that tells the browser to use only secure transport for that host for a stated period. After that, the browser rewrites HTTP requests to HTTPS and refuses to click through certificate errors.
The RFC also covers expiry choices and the includeSubDomains directive, which affects every subdomain including ones that still serve plain HTTP. Roll it out with a short lifetime first and lengthen it once you are sure.
A constructed example
A sales rep checks a customer portal from an airport network. A rogue access point answers DNS with its own address and presents a self-signed certificate.
On a laptop where the portal sent an HSTS header last week, the browser shows a hard error with no option to continue. On a phone running an internal app that disables certificate checks in a debug build left in production, the attacker reads the session token. The same network produced two outcomes because of one flag.
What else belongs on the list?
Verify software updates with signatures, not only with HTTPS. Use certificate pinning in mobile apps where you control both ends, and plan for rotation. Use a VPN or a zero trust access broker on untrusted networks. Monitor for unexpected certificates for your domains. The OWASP Transport Layer Security Cheat Sheet is a practical reference for protocol and cipher settings.
How to check or apply this
- Scan your public hosts and disable TLS versions below 1.2, preferring 1.3.
- Add the HSTS header, starting with a short max age, then raise it.
- Search your code and configs for disabled certificate verification.
- Fix mixed content so pages do not pull scripts over HTTP.
- Sign and verify software updates independently of the transport.
- Treat enrollment and device pairing flows as MITM targets and protect them.
- Alert on new certificates issued for your domains.
Quick check
Does HTTPS make a man-in-the-middle attack impossible?
No. It stops passive reading and tampering when certificates are validated. Attacks remain through bad validation, downgrade, a hostile root certificate or the first plain HTTP request.
What is the quickest code review check?
Search for any option that turns off certificate or hostname verification, and remove it from production paths.
Sources
- NIST glossary, man-in-the-middle attack
- RFC 8446, TLS 1.3
- RFC 6797, HTTP Strict Transport Security
- OWASP Transport Layer Security Cheat Sheet
Last reviewed: 18 October 2026.
