How does an SSL stripping attack work, and what stops it?

An SSL stripping attack is a downgrade attack in which a network attacker sits between a user and a site and keeps the user's browser on plain HTTP, while the attacker talks HTTPS to the real site. The defense is HTTP Strict Transport Security (HSTS), which tells browsers to use only HTTPS.

Where does the attack start?

Most people reach a site by typing a name or following an old link, which begins with an unencrypted HTTP request. The site then redirects the browser to HTTPS. That first request is the opening. An attacker who can sit on the path, for example on a shared wireless network, can intercept the request, fetch the real HTTPS site themselves, and return pages to the user over HTTP with the secure links rewritten. The user sees a working site and no warning. The attacker reads everything.

RFC 6797, the HSTS specification, describes the underlying threat model. A passive network attacker nearby can eavesdrop on unencrypted connections and steal session cookies to hijack sessions. An active network attacker can go further, by impersonating a user's DNS server or, on a wireless network, by spoofing frames or offering a similarly named evil twin access point. RFC 6797 also lists web site development and deployment bugs, such as loading a stylesheet over an insecure connection, as a way to compromise an otherwise secure site.

What does HSTS do?

A site sends a Strict-Transport-Security response header over HTTPS. The browser remembers the policy for the period given in max-age, and for that time it converts any request to that host into HTTPS before sending it, and refuses to continue if the connection has errors. An option, includeSubDomains, extends the policy to subdomains. RFC 6797 explains the need for it: without includeSubDomains, a site cannot adequately protect domain cookies, which are cookies set for every subdomain, even when they carry the Secure flag.

Because the browser upgrades requests itself, the unencrypted first hop disappears for returning visitors, and a stripping attacker has nothing to intercept.

What is the remaining gap?

The very first visit. RFC 6797 calls this the bootstrap MITM vulnerability: until the browser has seen the header once, it has no policy. The specification describes an HSTS preloaded list, where browser vendors ship the policy for listed sites in advance, in a manner similar to how root CA certificates are embedded in browsers, which would help protect against this gap.

HSTS also does not address everything. RFC 6797 states that phishing and malware or browser vulnerabilities are outside what it addresses.

A constructed example

A bank's site redirects HTTP to HTTPS but has no HSTS header. A customer opens a laptop in a cafe whose Wi-Fi is run by an attacker. The customer types the bank's name, the browser tries HTTP, and the attacker answers instead of the bank. The page looks normal and logins are captured. After the bank adds a header with a long max-age, includeSubDomains and preload eligibility, returning customers go straight to HTTPS, and the attacker's interception fails with a hard error.

How to check or apply this

1. Serve every page over HTTPS and fix mixed content, including scripts, styles and images.
2. Redirect HTTP to HTTPS on the same host.
3. Add the Strict-Transport-Security header with a long max-age on HTTPS responses.
4. Test every subdomain before adding includeSubDomains, because it will force HTTPS on all of them.
5. Consider submitting the domain to browser preload lists, once you are sure you can keep HTTPS working everywhere.
6. Set the Secure flag on cookies.
7. Train users to treat certificate errors as stop signs, not obstacles.

Quick check

Sources

• RFC 6797, HTTP Strict Transport Security (HSTS)
• MITRE ATT&CK T1557, Adversary-in-the-Middle

Last reviewed: 18 October 2026.