SSL stripping is a man-in-the-middle attack where an attacker, positioned between a visitor and a website, intercepts the initial plain-HTTP request (before any redirect to HTTPS happens) and quietly keeps the visitor on HTTP for the entire session — proxying their traffic to the real HTTPS site behind the scenes while showing the victim an unencrypted connection they don't notice.
Why it works
Many sites' HTTPS enforcement relies on a redirect: a visitor types or clicks a plain http:// link, connects insecurely for a moment, and only then gets redirected to https://. That brief unencrypted moment is exactly what SSL stripping exploits — the attacker never lets the redirect happen, so the browser never even attempts the secure connection.
The defense: HSTS
HTTP Strict Transport Security (HSTS) closes this gap by telling the browser, after the first successful HTTPS visit, to never attempt a plain HTTP connection to that domain again — even if a link or bookmark says http://. Submitting your domain to the HSTS preload list goes further, hardcoding that behavior into browsers themselves before a visitor ever connects for the first time.
Why this attack specifically targets the moment before encryption starts
SSL stripping doesn't attempt to break TLS directly — it exploits the brief window where a visitor's initial connection is still plain HTTP, before any redirect to HTTPS has completed, keeping the victim on HTTP for the entire session while the attacker proxies traffic to the real site behind the scenes.
Why HSTS in particular, not just a redirect, is the real defense
A server-level redirect alone still has that brief unencrypted moment on a visitor's very first connection; HSTS closes it by instructing the browser to never even attempt a plain HTTP connection to that domain again after the first successful HTTPS visit, removing the specific window SSL stripping depends on.
Why this attack is largely invisible to the victim while it's happening
A victim experiencing SSL stripping typically sees a normal-looking, functioning website with no obvious error or warning, since the attacker is actively proxying traffic to the real site behind the scenes — this lack of any visible symptom is exactly what makes the attack dangerous and why HSTS's proactive prevention matters more than after-the-fact detection.
Why public Wi-Fi remains the most realistic scenario for this attack today
Despite HSTS's widespread adoption significantly reducing SSL stripping's practical viability against protected domains, an unprotected domain accessed over public Wi-Fi, a coffee shop network, an airport hotspot, remains the clearest realistic scenario where an attacker could still successfully intercept a visitor's very first, unprotected connection.
How HSTS preloading closes the very last remaining gap standard HSTS leaves open
Standard HSTS still has one narrow gap: a visitor's first-ever connection to a domain, before any HSTS header has been received. Preloading closes this by hardcoding the HTTPS-only policy into browser source code, protecting even that very first connection with no prior visit required.
Why defense here is mostly about closing gaps proactively, not detecting attacks after the fact
Unlike some threats you can monitor for and respond to, SSL stripping is best addressed by proactively closing the gap it depends on, HSTS and preloading, rather than trying to detect an attack that's specifically designed to be invisible to the victim while it's happening.
What a security-conscious visitor can personally do to reduce this risk
Beyond relying on a site's own HSTS configuration, manually typing https:// explicitly rather than letting a browser default to http://, or using a browser extension that enforces HTTPS by default, gives an individual visitor some additional personal protection against this specific attack independent of any particular site's own configuration.
Loading comments…