SSL Stripping: Downgrading HTTPS to HTTP & the HSTS Defense

Type a website name into a browser without the scheme and something easy to miss happens. The browser often makes its very first request over plain HTTP, then follows a redirect to the HTTPS version. That redirect is where SSL stripping lives. An attacker sitting on the path catches that first plaintext request and never lets the browser reach HTTPS at all.

The result is a victim who thinks they are browsing normally while an attacker reads and rewrites everything in the clear. The clever part is that nothing gets decrypted, because nothing gets encrypted. The attacker simply prevents the secure connection from ever forming.

The plaintext moment

To see why stripping works, look at what happens when someone visits a site by typing a bare hostname. The browser has no instruction yet to prefer HTTPS, so it issues an HTTP request. A well-configured server responds with a redirect to the HTTPS address, and from there the connection is encrypted.

Between the plaintext request and the redirect there is a gap. For that one exchange, the traffic is unencrypted and unauthenticated. An attacker on the path can intercept it. This is the seam SSL stripping pries open.

How the downgrade works

SSL stripping requires the attacker to already be on-path, which they reach through the usual man-in-the-middle techniques catalogued under Adversary-in-the-Middle (T1557): ARP spoofing on a LAN, a rogue Wi-Fi access point, or DNS redirection. Once positioned, the attack runs like this.

• The victim's browser sends its initial plain HTTP request.
• The attacker intercepts it and, instead of passing along the server's redirect to HTTPS, opens its own proper HTTPS connection to the real server.
• The server talks HTTPS to the attacker, none the wiser. The attacker relays the content back to the victim over plain HTTP.
• The victim's browser renders a working page over HTTP. Every link the attacker serves points at HTTP too, so the victim stays on the unencrypted side for the whole session.

The attacker now sits in a comfortable position. They hold a legitimate encrypted session with the server and an unencrypted one with the victim, and they translate between the two. Everything the victim sends, logins, session cookies, form data, passes through the attacker as plaintext, ready to read or modify.

Crucially, no certificate warning fires. The attacker never presents a fake certificate to the victim, because the victim is on HTTP and expects no certificate at all. The absence of the padlock is the only visible sign, and it is exactly the sign most users never check.

Why this is different from breaking TLS

It helps to be precise about what SSL stripping does and does not do. It does not defeat TLS encryption, guess keys, or forge a certificate. Modern TLS, configured per guidance like NIST SP 800-52 Rev. 2, is not the thing under attack here.

What stripping attacks is the decision to use TLS at all. It exploits the fact that the browser started in plaintext and could be kept there. The cryptography is never engaged, so its strength is irrelevant. This is why the defense is not a better cipher but a rule that forces HTTPS from the first byte, before any plaintext request can be made.

HSTS closes the window

HTTP Strict Transport Security, defined in RFC 6797, is the direct answer. A server sends an HSTS response header telling the browser to use HTTPS for this site, and only HTTPS, for a specified duration.

Once a browser has seen that header, it changes behavior. For the duration of the policy, any attempt to reach that site over HTTP, whether the user typed a bare hostname or clicked an HTTP link, is upgraded to HTTPS internally by the browser before any request leaves the machine. There is no plaintext first request for an attacker to catch. The header looks like this:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

The pieces matter. The max-age sets how long the browser enforces HTTPS, and a long value such as two years is standard. The includeSubDomains directive extends the rule to every subdomain, so an attacker cannot strip a forgotten subdomain instead. The preload token signals intent to join the preload list, described next.

The first-visit gap and preload

HSTS has one honest weakness. The browser only learns the policy after it has seen the header at least once, which means the very first visit to a site can still start in plaintext. An attacker present at that first visit could strip it before the policy is ever recorded.

The HSTS preload list closes this. Browsers ship with a built-in list of domains that must always be reached over HTTPS, no prior visit required. A site owner submits their domain to the list, and once included, browsers enforce HTTPS for it from the first request a user ever makes. That removes the first-visit gap entirely.

Read down the table and the layers close successively. Preload is the row that finishes the job, at the cost of a commitment that is deliberately slow to reverse, which is why you turn it on only when you are confident every hostname is HTTPS-ready.

How to defend against SSL stripping

The defense is a short, well-worn checklist, and the ordering matters because each step depends on the one before.

1. Serve the whole site over HTTPS. Every page, asset, and subdomain. Stripping feeds on any resource still reachable over HTTP, so leave none.
2. Redirect HTTP to HTTPS. Return a permanent redirect from HTTP to HTTPS on every entry point, so direct HTTP visitors land on the secure version.
3. Send HSTS with a long max-age. Use a value such as two years, and include includeSubDomains so no subdomain is left as an open door.
4. Preload the domain. Once you are certain every subdomain supports HTTPS, add the preload token and submit to the preload list to close the first-visit gap.
5. Harden the network path. Because stripping needs an on-path position, the controls that stop ARP spoofing and rogue access points, and encrypted DNS that stops redirection, also cut off the route to the attack.
6. Use a VPN on untrusted networks. On public Wi-Fi, an authenticated tunnel back to a trusted endpoint removes the local on-path opportunity entirely.

For a view of which adversaries use downgrade and interception techniques as part of their operations, our Threat Group Directory maps groups to the on-path methods they favor.

A stripping session, walked through

Tracing the attack step by step makes clear why HSTS lands exactly where it does. Picture a victim on an open Wi-Fi network where the attacker has already reached an on-path position, and the victim types a bare hostname with no scheme.

The browser, having no stored instruction to prefer HTTPS for this site, issues its first request over plain HTTP. On a clean network the server would answer with a redirect to the HTTPS address and the browser would follow it into an encrypted session. The attacker intercepts that first plaintext request before the redirect can take effect.

Instead of relaying the server's redirect, the attacker opens its own proper HTTPS connection to the real server. To the server, the attacker looks like an ordinary client on a secure connection, so the server responds normally and the certificate validates cleanly on the attacker's side. The attacker takes the content the server returns and relays it to the victim over plain HTTP, rewriting every HTTPS link in the page to its HTTP form so the victim has no path back to the secure version.

The victim's browser renders a working page. There is no certificate warning, because the browser is on HTTP and expects no certificate at all. Every subsequent click stays on the attacker's HTTP side, and every login, cookie, and form field the victim submits passes through the attacker in the clear before being forwarded onward over the real HTTPS session. The attacker sits between two connections, encrypted toward the server and plaintext toward the victim, translating and reading everything in between.

Now replay the same sequence with HSTS in force. The browser has previously seen the site's HSTS header, or the domain is on the preload list, so before the first request leaves the machine the browser upgrades the bare hostname to HTTPS internally. There is no plaintext request on the wire for the attacker to intercept. The step the entire attack hinges on never happens, and the on-path position that was so powerful a moment ago has nothing to grab.

Detection signals

Stripping is designed to look normal to the victim, so detection leans on the network and the server side more than on anything the user notices. Concrete indicators worth watching for:

• Plaintext HTTP requests for hosts that should always be HTTPS. On a network you monitor, a client sending cleartext requests to a hostname you know enforces HTTPS suggests something is keeping it on the unencrypted side.
• A drop in expected HTTPS sessions relative to HTTP for a known site. When a population that normally connects over HTTPS starts showing cleartext traffic to the same destinations, an on-path downgrade is one explanation worth ruling out.
• Server-side requests arriving over HTTP from clients that normally use HTTPS. From the server's vantage, a sudden rise in plaintext requests, or requests missing the expected HSTS-driven upgrade behaviour, can indicate downgrade activity between the client and the server.
• The on-path precursors themselves. Stripping needs a man-in-the-middle position, so the LAN-level signals that reveal ARP spoofing, a rogue DHCP server, or an unexpected access point broadcasting a familiar network name are early warnings of the setup that enables it.
• Mixed-content and link-rewriting artefacts. Pages served with their HTTPS links rewritten to HTTP, or unexpected mixed-content patterns, can be a fingerprint of content relayed and rewritten by a stripping proxy.
• Clients that never record an HSTS policy for sites that send one. A browser that keeps making plaintext first requests to a site known to send HSTS may be having that header stripped before it arrives.

How stripping compares to related attacks

SSL stripping is easy to confuse with other attacks that touch encrypted connections. The distinctions point to different defenses.

Stripping stands apart because it never engages the cryptography and never presents a certificate, so it produces no warning at all. Fake-certificate interception does engage TLS and therefore trips validation unless the attacker's certificate is somehow trusted. Handshake downgrade weakens an encrypted session rather than preventing it. DNS spoofing and rogue access points are often the means of reaching the on-path position from which stripping is then launched, which is why the network-hardening controls that stop them also cut off the route to stripping. The common thread across the family is catalogued under Adversary-in-the-Middle (T1557).

Common misconceptions

A few widespread beliefs get SSL stripping wrong in ways that weaken defenses.

• "We have a valid TLS certificate, so we are safe from stripping." A certificate secures connections that actually reach TLS. Stripping keeps the victim on HTTP where no certificate is involved, so the certificate is never exercised. The control that helps is HSTS, which forces the browser to HTTPS before any plaintext request, and preload, which does so even on a first visit.
• "Redirecting HTTP to HTTPS is enough." The redirect only helps if the browser reaches your server over HTTP and receives it. An on-path attacker intercepts the plaintext request and never delivers your redirect, substituting its own relayed content instead. The redirect is necessary, and HSTS is what removes the plaintext request the redirect depends on.
• "Users will see something is wrong." The attack raises no certificate error and the only visible sign is a missing padlock, which most users do not check and which is easy to disguise. Relying on user vigilance is not a defense.
• "Stripping breaks or weakens TLS." It does neither. It prevents TLS from starting by exploiting the plaintext first request. The strength of your ciphers is irrelevant to it, which is why the fix is a policy that forces HTTPS from the first byte rather than a stronger algorithm.
• "HSTS with a short max-age is fine." A short policy expires quickly, reopening the window where a browser will again make a plaintext first request. A long max-age, commonly around two years, keeps the policy in force between visits, and includeSubDomains prevents stripping via a forgotten subdomain.

How the defense evolved

SSL stripping became a named, practical technique at a time when a large share of the web still served its login pages and sometimes its whole session over plain HTTP, with HTTPS reserved for a narrow set of steps. In that world the plaintext first request was the norm rather than a brief seam, and an on-path attacker had a wide, comfortable window to keep a victim on the unencrypted side. The response came in layers. Sites moved to serving everything over HTTPS with a redirect, which shrank the plaintext exposure to the initial request. HSTS then removed that initial request for returning visitors by teaching the browser to upgrade to HTTPS before anything left the machine. The preload list closed the remaining first-visit gap by shipping the HTTPS rule inside the browser itself. In parallel, browsers grew more assertive about defaulting to HTTPS and warning on cleartext, and the wide adoption of free, automated certificates removed the cost excuse for running plaintext at all. The trajectory is consistent: from an internet where plaintext was expected, to one where the browser refuses to start in plaintext for a growing set of sites, which steadily starves the attack of the unencrypted moment it needs.

Frequently asked questions

Does SSL stripping break TLS encryption? No. It never engages TLS at all. The attack keeps the victim on plain HTTP by intercepting the initial plaintext request and relaying content over HTTP, while the attacker holds a normal HTTPS session with the real server. Because the cryptography is never used on the victim's side, the strength of the encryption is irrelevant, which is why the defense is a policy that forces HTTPS rather than a better cipher.

Why does no certificate warning appear during stripping? Certificate warnings fire when a browser is on an HTTPS connection and something is wrong with the certificate. During stripping the victim is on HTTP, where no certificate is expected, so nothing triggers a warning. The only visible sign is the absence of the padlock, which most users do not check and which an attacker can obscure with a lookalike favicon.

How does HSTS actually stop the attack? HSTS tells the browser to use HTTPS for a site, and only HTTPS, for a set duration. Once the browser has that policy, any attempt to reach the site over HTTP is upgraded to HTTPS internally before a request leaves the machine. That removes the plaintext first request the attack depends on, so an on-path attacker has nothing to intercept.

What is the first-visit gap and how does preload close it? A browser only learns a site's HSTS policy after it has seen the header at least once, so the very first visit to a site can still begin over plaintext, and an attacker present at that moment could strip it. The HSTS preload list closes this by shipping a built-in list of domains that browsers enforce as HTTPS-only from the first request ever made, with no prior visit required.

Is HTTPS everywhere enough on its own without HSTS? Serving everything over HTTPS with a redirect from HTTP is necessary groundwork, and it prevents passive exposure once a connection is secure. It does not stop stripping by itself, because an on-path attacker intercepts the initial plaintext request and never lets the redirect take effect. HSTS, and preload for the first visit, are what remove that plaintext request entirely.

Does a VPN protect against SSL stripping? On an untrusted network, an authenticated VPN tunnel back to a trusted endpoint removes the local on-path opportunity, because the attacker on the local segment can no longer sit between the victim and the sites they visit. It is a strong control for public Wi-Fi. For the sites themselves, HSTS with preload is the durable protection that travels with the site regardless of what network the user is on.

What is the relationship between SSL stripping and man-in-the-middle attacks? SSL stripping is a specific technique that requires a man-in-the-middle, or on-path, position to work. The attacker reaches that position through general man-in-the-middle methods such as ARP spoofing, a rogue access point, or DNS redirection, all catalogued under Adversary-in-the-Middle (T1557), and then uses stripping to keep the victim on HTTP. Hardening the network against those on-path techniques also cuts off the route to stripping.

SSL stripping is a reminder that the weakest point of an encrypted connection is often the instant before it becomes encrypted. The attack does not break TLS; it stops TLS from starting. Serve HTTPS everywhere, enforce it with HSTS, and preload the domain, and the plaintext window that stripping depends on simply closes.

Related guides

• Man-in-the-Middle Attacks Explained
• HSTS Explained
• How HTTPS Works
• How the TLS Handshake Works