Why You Need To Know About HSTS and SSL Stripping Attack?

An SSL stripping attack (also called HTTPS stripping) downgrades a victim’s encrypted HTTPS connection to unencrypted HTTP, allowing an attacker positioned between the user and the server to read all transmitted data including passwords, session cookies, and payment card numbers. HTTP Strict Transport Security (HSTS) is the primary defense: it instructs browsers to always use HTTPS for a domain, preventing the downgrade by upgrading HTTP requests to HTTPS on the client side before they reach the network. The recommended action: deploy HSTS with a minimum max-age of one year, the includeSubdomains directive, and the preload flag, and ensure all subdomains hold valid TLS certificates before enabling HSTS.

Quick Answer: What Are SSL Stripping and HSTS?

An SSL stripping attack intercepts the moment a browser follows an HTTP-to-HTTPS redirect and swaps the HTTPS links back to HTTP, keeping the victim on an unencrypted connection while the attacker maintains an HTTPS connection to the server. Neither the browser nor the server detects the attack. HSTS defeats this by recording a domain’s HTTPS-only policy in the browser; on subsequent visits, the browser upgrades HTTP requests to HTTPS before sending them, so there is no HTTP request for an attacker to intercept and redirect. The HSTS preload list eliminates the remaining first-visit vulnerability by hardcoding the policy in browser builds.

Why HTTPS Adoption Did Not Eliminate Stripping Attacks

Technologies such as HTTPS, combining HTTP and TLS, provide confidentiality and integrity for web browsing. The availability of free TLS certificates through automated issuance has dramatically expanded HTTPS adoption. However, HTTP connections still exist across the internet, and browsers must handle both protocols. When a user types a domain name without specifying a protocol, the default request is HTTP. This is the gap that SSL stripping exploits.

How an SSL Stripping Attack Works

HTTPS stripping attacks have been a documented concern since Moxie Marlinspike demonstrated sslstrip at the Black Hat conference in 2009. The attack proceeds in five steps:

1. Attacker positions as man-in-the-middle: using ARP spoofing, a rogue Wi-Fi access point, or another interception technique, the attacker routes the victim’s traffic through their machine.
2. Victim sends HTTP request: the user types example.com without https:// and the browser sends an HTTP request. The attacker intercepts this request.
3. Attacker forwards request to server: the attacker forwards the request to the legitimate server over HTTPS, maintaining an encrypted connection with the server.
4. Server sends HTTPS redirect: the server responds with a 302 redirect to its HTTPS version. The attacker intercepts this response and replaces all https:// links with http:// before forwarding it to the victim’s browser.
5. Victim continues over HTTP: the browser receives a response with HTTP links and continues over an unencrypted HTTP connection to the attacker. All data transmitted including credentials, session tokens, and payment card numbers is visible in plaintext to the attacker.

The attack is undetectable by the server (it communicates with the attacker over HTTPS) and difficult for the user to notice (the URL bar shows http:// but users rarely check).

HSTS Protocol: How It Prevents Stripping

HTTP Strict Transport Security (HSTS) was introduced in RFC 6797 in 2012 specifically to defend against HTTPS stripping. When a server sends an HSTS policy via the Strict-Transport-Security response header, the browser records the domain and refuses to connect to it over HTTP for the duration of the policy. On subsequent visits, the browser converts HTTP requests to HTTPS internally before sending any network request, so there is no HTTP request for an attacker to intercept.

The HSTS header consists of three fields:

• max-age (required): specifies in seconds how long the browser should enforce the HTTPS-only policy. A value of 31536000 equals one year. The browser resets this timer on each HSTS header received, so long-lived sessions keep the policy fresh.
• includeSubdomains (optional but strongly recommended): extends the HSTS policy to all subdomains of the domain. Without this directive, an attacker could use an HTTP subdomain connection as a stepping stone to strip the main domain’s connection.
• preload (optional but recommended for high-security domains): flags the domain for inclusion in browser HSTS preload lists maintained by browser vendors. Preloaded domains have HSTS enforced even on the first visit, eliminating the first-visit vulnerability.

A complete HSTS configuration header for maximum security looks like this:

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

HSTS headers can only be sent over HTTPS connections. An attacker cannot inject a false HSTS header via HTTP to disable HSTS protection, as browsers ignore Strict-Transport-Security headers received over HTTP.

Threat Model: When HSTS Applies and When It Does Not

Scenario	HSTS protection status	Remaining risk
Returning visitor to HSTS-enabled domain (browser has cached policy)	Protected: browser upgrades HTTP to HTTPS client-side	None from stripping; attacker cannot intercept an HTTP request that was never sent
First-time visitor to HSTS-enabled domain not on preload list	Vulnerable to stripping on first visit before HSTS header is received	First-visit attack window; mitigated only by preloading
Domain on HSTS preload list	Protected even on first visit	None from stripping; HSTS is hardcoded in the browser
Subdomain not covered by includeSubDomains	Subdomain connection can be stripped	Attacker can use subdomain HTTP connection to serve malicious content or steal session data
Expired TLS certificate on an HSTS-protected domain	HTTPS fails; browser shows hard error; user cannot visit site	Denial of service; HSTS prevents HTTP fallback, so an expired cert hard-blocks access

HSTS Limitations

• First-visit vulnerability: HSTS cannot protect a user who has never visited the domain before and whose browser has no cached HSTS policy. The only solution is preloading.
• Preload list maintenance: submitting to the preload list is permanent in practice. Removing a domain from the preload list requires browsers to release new builds that remove it, a process that takes months to years to propagate. Organizations that enable preloading must be permanently committed to HTTPS for the domain and all subdomains.
• Subdomain coverage requires readiness: enabling includeSubDomains breaks access to any subdomain that is not HTTPS-capable. Organizations must audit all subdomains for TLS certificate coverage before enabling this directive.
• Cannot be bypassed through HTTP header injection: while this is a security property (HSTS headers via HTTP are ignored), it also means that HSTS cannot be revoked through HTTP. If an organization needs to disable HSTS (for example during a TLS migration), it must serve a max-age=0 response over HTTPS before removing HTTPS support.

Key Management Dependencies: HSTS Requires Valid TLS Certificates

HSTS is entirely dependent on the TLS certificates that enable HTTPS. A domain with an expired TLS certificate cannot serve HTTPS and therefore cannot deliver HSTS headers to new visitors. More critically, because HSTS prevents browsers from falling back to HTTP, an expired TLS certificate on an HSTS-protected domain results in a hard browser error rather than a quiet degradation: the site becomes completely inaccessible.

The CA/Browser Forum has mandated progressively shorter TLS certificate lifetimes: 200 days maximum from March 2026, 100 days from 2027, and 47 days by 2029. At these lifetimes, manual certificate management for HSTS-protected sites is not viable. An expired certificate on an HSTS-protected domain causes a hard outage for all users whose browsers have cached the HSTS policy. Automated certificate lifecycle management is a prerequisite for sustainably deploying HSTS at scale. See CertSecure Manager and our guide on 47-day TLS certificate lifetimes.

How Encryption Consulting Can Help

• CertSecure Manager: HSTS-protected domains require continuously valid TLS certificates. CertSecure Manager automates TLS certificate discovery, renewal, and policy enforcement, preventing the hard-outage scenario caused by expired certificates on HSTS-protected sites. This matters especially as certificate lifetimes drop to 47 days by 2029.
• PKI as a Service: organizations deploying HSTS across many domains or subdomains need reliable certificate issuance infrastructure. PKI as a Service provides managed certificate authority infrastructure, ensuring every domain and subdomain in the HSTS scope has a valid certificate from a trusted CA.
• Encryption Advisory Services: our Encryption Advisory Services assess TLS configurations across all HSTS-protected domains and subdomains, identify gaps in certificate coverage, verify HSTS header configurations, and recommend remediation aligned to current security standards.

Conclusion

HSTS is the standard mechanism for preventing SSL stripping attacks, but its effectiveness depends on correct configuration and on the underlying TLS certificates remaining valid. An SSL stripping attack exploits the gap between a user’s HTTP request and the server’s HTTPS redirect; HSTS closes that gap by having the browser enforce HTTPS internally before any HTTP request reaches the network. Deploy HSTS with a full one-year max-age, the includeSubdomains directive, and the preload flag for all production domains. Ensure all subdomains have valid TLS certificates before enabling includeSubdomains. Use automated certificate lifecycle management to prevent the hard-outage scenario that results from an expired certificate on an HSTS-protected domain. For related reading, see our detailed guide to preventing SSL stripping and our post on TLS 1.2 and TLS 1.3.

Frequently Asked Questions

What is an SSL stripping attack?

A man-in-the-middle attack that downgrades a victim’s HTTPS connection to HTTP by intercepting 302 redirects and substituting HTTP links. The attacker reads all data in plaintext while maintaining HTTPS to the server. Neither the browser nor the server detects the attack.

What is HSTS and how does it prevent SSL stripping?

HSTS (HTTP Strict Transport Security, RFC 6797) instructs browsers to always use HTTPS for a domain. The browser converts HTTP requests to HTTPS internally before sending them, so no HTTP request ever reaches the network for an attacker to intercept. HSTS prevents stripping on subsequent visits; the preload list extends this to first visits.

What are the three HSTS header fields?

max-age (required): how long in seconds the browser enforces HTTPS-only for the domain (31536000 = one year). includeSubdomains (optional): extends the policy to all subdomains. preload (optional): flags the domain for inclusion in browser preload lists, eliminating the first-visit vulnerability.

What is the HSTS first-visit vulnerability?

On a user’s first visit, no HSTS policy is cached yet, so the browser allows an HTTP connection. If intercepted at this point, an SSL stripping attack succeeds before HSTS is established. The only mitigation is the HSTS preload list, which hardcodes HSTS policies in browsers so they apply even on first visit.

How should HSTS be configured for maximum security?

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. All subdomains must have valid TLS certificates before enabling includeSubDomains. The domain must be submitted to hstspreload.org for preload inclusion. Once preloaded, removal takes months to propagate through browser releases.

What certificates and PKI components support HSTS?

HSTS depends on valid TLS certificates on all domains and subdomains in scope. An expired certificate on an HSTS-protected domain causes a hard browser error (not a silent HTTP fallback), making the site inaccessible. With certificate lifetimes dropping to 47 days by 2029, automated certificate lifecycle management is required for any organization deploying HSTS at scale.