SSL Stripping (HTTPS-to-HTTP downgrade)

SSL stripping was presented by Moxie Marlinspike in 2009 together with his sslstrip tool. An attacker on the network path, for example on shared Wi-Fi, intercepts the victim's first plaintext request; users typically type example.com without a scheme. Instead of passing the server's redirect to HTTPS back to the victim, the attacker fetches the HTTPS site itself and relays it over HTTP, rewriting https:// links to http://. The victim never sees a certificate warning, because no TLS connection to the victim is ever attempted.

Why it matters

It defeats HTTPS without breaking any cryptography, by exploiting the plaintext step before TLS begins. A server-side 301 redirect does not help, since the attacker controls that response. The defenses live in the browser: HSTS makes it upgrade to HTTPS internally before any request leaves the machine, and HSTS preload does the same even for the first visit. HTTPS-first and HTTPS-only browser modes reduce exposure further. SSL stripping is a specific form of man-in-the-middle attack and a close relative of protocol downgrade attacks.

Example

Victim   -> http://example.com           intercepted by the attacker
Attacker -> https://example.com          real TLS connection to the server
Attacker -> Victim: HTTP copy of the page, every https:// link rewritten to http://

Check that a site has the defenses in place:

curl -sI http://example.com  | grep -i '^location'
curl -sI https://example.com | grep -i strict-transport-security

Common misconceptions

• Redirecting HTTP to HTTPS prevents SSL stripping. The redirect travels over HTTP and the attacker can simply not forward it; only HSTS stops the browser from sending that request.
• A site without a login page has nothing worth stripping. An attacker can inject scripts, ads or fake download links into any page served over HTTP.
• Users would notice a certificate error. There is no error; the victim just sees an http:// address, which many users never check.