SSL Stripping (HTTPS Downgrade)
Also known as: SSL strip, HTTPS downgrade, HTTP downgrade attack, TLS stripping
An on-path attack on a hostile network that keeps a victim on plain HTTP while talking HTTPS to the real server, so credentials and sessions travel in the clear.
How it works
SSL stripping is a downgrade attack on an on-path position, such as a hostile or compromised network. The victim's browser starts a connection over plain HTTP, as users often do when they type a bare domain name. An on-path system keeps the victim on HTTP while it speaks HTTPS to the real server, so the server sees a normal encrypted session and the user sees a working site with no padlock.
The weakness is not in TLS itself. It is that the first request, and any link or redirect that points at http://, is unauthenticated and unencrypted, so the browser has no way to know the site was meant to be secure. Everything the user then types, including passwords and session cookies without the Secure flag, crosses the network in cleartext.
Defenders see this as inconsistencies. Users of a site that is HTTPS-only on the server side appear in proxy or endpoint logs on http://, secure-by-design pages are served with no Strict-Transport-Security header, assets are fetched over HTTP on HTTPS pages (mixed content), and an unexpected network device appears on the path.
The decisive fix is to tell the browser, ahead of time and for a long time, never to use HTTP for the site. HSTS does this, preload lists remove the first-visit gap, and Secure cookies plus a clean HTTPS-only site ensure that nothing sensitive is ever sent in the clear even if a downgrade is attempted.
Walk through it
- 1Spot the downgrade
- 2Read the response headers
- 3Write the HSTS policy
- Cookies and mixed content
- Enforce HTTPS-only everywhere
A customer on the cafe Wi-Fi reports that the company's account page 'worked fine' but showed no padlock. The page is meant to be HTTPS only. Read the address bar and name the scheme the user was really on.
Sign in to your account
The address bar shows a 'Not secure' marker and no padlock.
The server's own configuration says this site is HTTPS only.
The customer typed a username and password into this form.
Spot it
- Proxy or endpoint logs show users reaching a site over http:// that the server enforces as HTTPS only.
- Responses from a host that should send Strict-Transport-Security arrive without it.
- HTTPS pages that load scripts, images or forms from http:// URLs (mixed content warnings in browser telemetry).
- Credential or session-cookie values observed in cleartext in network captures on untrusted segments.
- Certificate or redirect anomalies: unexpected redirect chains, a different certificate for the host, or a new device on the network path.
- A spike in plain-HTTP requests for a domain from one client network, where HTTPS is normal.
Web proxy / secure web gateway
ts=2026-10-11T10:02:11Z user=cust-4471 method=POST url=http://accounts.contoso-coffee.example/login status=302 bytes=412 client_net=guest-wifi
ts=2026-10-11T10:02:12Z user=cust-4471 method=GET url=http://accounts.contoso-coffee.example/account status=200 bytes=18214 client_net=guest-wifiEdge / CDN response log
ts=2026-10-11T10:05:40Z host=accounts.contoso-coffee.example scheme=https status=200 resp_hsts=absentkqlPlain HTTP to a host that should be HTTPS only
ProxyLogs
| where Url startswith "http://"
| where Host endswith "contoso-coffee.example"
| summarize requests = count() by Host, ClientNetwork, bin(Timestamp, 1h)
| order by requests descAssumes a proxy log table; scope to hosts whose policy is HTTPS only.
splHTTPS responses missing HSTS
index=edge scheme=https status=200 host=*.contoso-coffee.example
| where isnull(resp_hsts) OR resp_hsts="absent"
| stats count by hostField names depend on your edge log schema.
Stop it
Send HSTS with a long max-age, includeSubDomains and preload
Strict-Transport-Security tells the browser to use HTTPS only for the host, so it refuses to start on HTTP at all. A long max-age (a year or more) keeps the protection active, includeSubDomains covers sibling hosts, and submitting to the preload list removes the unprotected first visit.
Redirect HTTP to HTTPS and serve nothing sensitive over HTTP
Redirect every HTTP request to HTTPS at the edge, keep the HTTP listener only for that redirect, and never load scripts, forms or API calls from http:// URLs. A redirect alone is weak, which is why HSTS comes first.
Protect sessions and clients
Mark session cookies Secure (and HttpOnly) so they are never sent over HTTP, enable HTTPS-only modes on managed browsers, and use a VPN or zero-trust path on untrusted networks.
HSTS response header
Vulnerable
HTTP/2 200
content-type: text/htmlHardened
HTTP/2 200
content-type: text/html
strict-transport-security: max-age=31536000; includeSubDomains; preload
set-cookie: session=...; Path=/; Secure; HttpOnly; SameSite=LaxRoll out with a short max-age first, then raise it, and only add preload once every subdomain supports HTTPS.
- Send Strict-Transport-Security on every HTTPS response with max-age of at least one year.
- Add includeSubDomains once all subdomains serve HTTPS, then submit the domain for browser preloading.
- Redirect all HTTP to HTTPS at the edge and remove HTTP-only endpoints.
- Set the Secure flag on all cookies that carry sessions or tokens.
- Eliminate mixed content and use a Content-Security-Policy with upgrade-insecure-requests while cleaning up.
- Enable HTTPS-only or HTTPS-first mode in managed browsers and tell staff to treat a missing padlock on a login page as a stop sign.
If it already happened
Ship the HSTS header and an edge-wide HTTP-to-HTTPS redirect now, and advise users not to sign in over shared Wi-Fi until it is live.
Identify accounts that signed in over plain HTTP from the affected network, force password resets and revoke their active sessions.
Mark all session cookies Secure, remove mixed content, raise HSTS max-age gradually, and submit the domain to the preload list when ready.
Add the plain-HTTP and missing-HSTS detections to monitoring, and add header checks to the release pipeline so the control cannot silently regress.
Check yourself
1. A site is HTTPS only on the server, yet proxy logs show users reaching it over http:// from guest Wi-Fi. What is the most likely explanation?
2. Which control most directly stops a browser from ever starting a connection to your site over plain HTTP?
3. Why should session cookies carry the Secure attribute even when the site has HSTS?