A man-in-the-middle (MITM) attack is when someone positions themselves between two communicating parties — a visitor and a website, in this context — and intercepts, reads, or alters the traffic passing between them, typically without either party realizing it's happening. SSL/TLS exists, fundamentally, to make this attack ineffective.
Where MITM attacks typically happen
- Public Wi-Fi — an attacker on the same network, or running a fake access point with a legitimate-looking name, can intercept unencrypted traffic from anyone who connects.
- Compromised or malicious routers — a router with altered DNS settings can silently redirect traffic toward an attacker's infrastructure.
- Corporate or ISP-level interception — some networks intentionally inspect traffic via installed root certificates (a legitimate but distinct scenario from malicious MITM).
Why a valid certificate is the thing an attacker can't fake
An attacker positioned on the network path can absolutely see and redirect traffic — that part of the attack is easy. What they cannot do is present a certificate for your domain that's signed by a CA in the visitor's trust store, because doing so would require either compromising a CA (extraordinarily difficult and immediately detectable via Certificate Transparency logs) or somehow obtaining your actual private key. Without a valid certificate, the browser either refuses the connection outright or shows an explicit warning — which is the entire security model working as intended.
What TLS actually prevents versus what it doesn't
TLS prevents an attacker from reading or silently modifying encrypted traffic, and prevents them from convincingly impersonating your domain without a valid certificate. It does not prevent an attacker from seeing that a connection to your domain is happening at all (the domain name itself, via SNI, is typically visible even in encrypted TLS 1.2 traffic, though TLS 1.3 with Encrypted Client Hello can hide this too), and it does nothing to protect against attacks that don't depend on intercepting the connection at all — phishing, malware, or social engineering happen entirely outside what a certificate can address.
SSL stripping: the attack that targets the gap, not the encryption
Rather than trying to break TLS directly, SSL stripping attacks target the brief moment before encryption is established — intercepting a visitor's initial plain-HTTP request before a redirect to HTTPS occurs, and simply keeping them on HTTP for the entire session rather than letting the upgrade happen. This is why HSTS (which tells browsers to never attempt plain HTTP to a domain in the first place) is considered an essential companion to a basic HTTPS redirect, not an optional extra.
What this means for you as a site owner
- Enforce HTTPS everywhere, with HSTS, so there's no unencrypted window for an attacker to exploit
- Keep your private key strictly confined to systems that need it — a leaked key is the one thing that lets an attacker genuinely impersonate your domain
- Monitor Certificate Transparency logs for unexpected certificates issued for your domain, which would indicate a compromised CA or hosting account rather than a network-level MITM
Notable real-world incidents worth knowing about
The 2011 compromise of the Dutch CA DigiNotar is the clearest illustration of what a successful attack on the certificate system itself looks like: attackers issued fraudulent certificates for major domains (including Google's), which were then used to intercept traffic for a large number of users, primarily in Iran. The incident was ultimately detected through Certificate Transparency-style monitoring and unusual certificate reports, and it led directly to DigiNotar being distrusted by every major browser within weeks — effectively ending the company. It's the reference case for why CA security and audit requirements are treated as seriously as they are, and why Certificate Transparency became a mandatory requirement afterward rather than an optional practice.
Defense in depth: what to layer on top of TLS
TLS handles the transport-layer trust problem, but a complete defense against interception-style attacks usually layers additional protections on top: HSTS (covered above) to close the pre-encryption gap, Certificate Transparency monitoring to catch fraudulent certificates quickly, and for especially high-value applications, certificate pinning to guard against the (rare, but real) scenario of a compromised or coerced CA. None of these replace TLS — they each address a specific, narrow gap in the parts of the trust chain that TLS alone doesn't fully close on its own.
Why public Wi-Fi specifically is the classic scenario
Public Wi-Fi networks are the textbook example of a man-in-the-middle risk because an attacker on the same network segment, or running a fake access point with a legitimate-looking name, can position themselves directly between you and the internet — TLS is specifically designed so that even in this exact scenario, they can't read or tamper with your encrypted traffic without your browser flagging an invalid certificate.
What a visitor should actually do when they see a certificate warning
If you hit a certificate warning on public or untrusted Wi-Fi specifically, don't click through — that's precisely the scenario this class of attack is designed to exploit. On a trusted home network, it's more likely a routine misconfiguration on the site's end, but it's still worth avoiding entering sensitive information until it's resolved, since you can't be fully certain which scenario you're in from the warning alone.
What TLS specifically does and doesn't prevent here
TLS prevents an attacker from reading or silently modifying encrypted traffic, and prevents convincing impersonation without a valid certificate. It does not prevent an attacker from seeing that a connection to your domain is happening at all in TLS 1.2 (the hostname is typically visible via SNI), though TLS 1.3 with Encrypted Client Hello can hide even this in supporting configurations.
SSL stripping: the attack that targets the gap before encryption starts
Rather than trying to break TLS directly, SSL stripping targets the brief moment before encryption is established — intercepting a visitor's initial plain-HTTP request before a redirect to HTTPS occurs, and simply keeping them on HTTP for the entire session. This is exactly why HSTS, which tells browsers to never attempt plain HTTP to a domain in the first place, is considered an essential companion to a basic redirect.
TLS was fundamentally designed around defeating exactly this attack, which is why a valid certificate check succeeding is such a strong practical guarantee, and why a certificate warning deserves to be taken seriously rather than clicked through reflexively.
A quick closing checklist for staying protected against this class of attack
Never click through a certificate warning on unfamiliar or public networks, keep your browser and OS updated for the latest trust store and security patches, and enable HSTS on any site you operate — three habits addressing both sides of this risk.