HTTP Downgrade and Mixed Content Risks

The HTTP Strict Transport Security (HSTS) header instructs browsers to only connect to a site over HTTPS for a specified period. Once received, the browser refuses HTTP connections and automatically upgrades http:// URLs to https://.

A typical HSTS header: "Strict-Transport-Security: max-age=31536000; includeSubDomains; preload". The max-age is in seconds (31536000 = 1 year). Once cached, the browser enforces HTTPS for one year without any server involvement.

The max-age parameter sets how long the browser should enforce HTTPS-only connections, in seconds. Recommended values are at least one year (31536000) for production sites.

The includeSubDomains directive extends HSTS enforcement to all subdomains. This prevents attacks where an attacker downgrades a subdomain connection to HTTP and uses it to steal cookies set without the Secure flag on the main domain.

Browsers ship with a hardcoded list of domains that are always HTTPS-only, even on the first ever visit. This list, maintained at hstspreload.org, includes thousands of major websites.

Preloading eliminates the first-visit vulnerability: without preloading, a first-time visitor could be intercepted before receiving the HSTS header. Preloaded sites are HTTPS-only from the very first request, regardless of HSTS cache state.

SSL stripping, published by Moxie Marlinspike at Black Hat 2009, is a MITM attack that downgrades HTTPS connections to HTTP. The attacker intercepts the user's initial HTTP request, makes HTTPS requests to the real server on the user's behalf, and forwards the content over HTTP to the user.

The victim sees content normally but over HTTP. Any credentials entered go to the attacker. Before HSTS, this attack was highly effective because users did not notice the missing padlock.

HSTS defeats SSL stripping because the browser refuses to proceed with HTTP connections to HSTS-enrolled domains. Even if an attacker tries to serve a page over HTTP, the browser simply refuses to connect and shows an error.

The browser's HSTS enforcement happens before any network request, so the attacker cannot interfere. The only remaining vulnerability is the first visit before HSTS is received, which preloading eliminates.

Mixed content occurs when an HTTPS page loads resources over HTTP. Passive mixed content includes images, audio, and video loaded over HTTP. They cannot directly modify the page but can reveal user information via HTTP headers and allow tracking.

Active mixed content includes scripts, stylesheets, iframes, and XMLHttpRequests loaded over HTTP. An HTTP script can completely compromise the HTTPS page's security because it has full DOM access and can read cookies and form data.

Modern browsers block active mixed content (scripts, stylesheets, iframes over HTTP) by default when the enclosing page is HTTPS. A console error is shown, and the resource is not loaded.

Starting with Chrome 81 (2020), browsers began automatically upgrading passive mixed content to HTTPS. If the HTTPS version exists, it is loaded. If not, the resource is blocked.

The browser's developer console shows mixed content warnings and errors. In Chrome, open DevTools, go to the Console tab, and filter by "Mixed Content". Each blocked resource shows the insecure URL that needs to be updated.

The Security panel in DevTools shows a comprehensive security overview: certificate details, connection information, and a list of all insecure resources on the page.

The Content Security Policy (CSP) directive "upgrade-insecure-requests" instructs browsers to automatically upgrade all HTTP requests from the page to HTTPS. This handles legacy content with hardcoded HTTP URLs.

Unlike blocking mixed content, upgrade-insecure-requests attempts to fetch the HTTPS version first. It is useful during migration from HTTP to HTTPS when updating all embedded URLs in legacy content would be impractical.

Without HTTPS, ISPs can inject content into HTTP responses. Several ISPs have been caught injecting advertisements into web pages that did not have ads, adding tracking pixels, or injecting warning pages when users approach their data cap.

This form of content injection is impossible on HTTPS pages because the response is authenticated and encrypted. Any modification would cause TLS MAC verification to fail, resulting in a connection error rather than modified content being served.

Before a browser has seen an HSTS header for a domain, the very first visit over HTTP is vulnerable. An attacker can intercept this initial request and perform SSL stripping without triggering any browser warnings.

This "trust on first use" vulnerability is why the HSTS preload list exists. Submitting a site to the preload list ensures browsers enforce HTTPS for that domain from the very first request, closing the first-visit window entirely.

Test your understanding of HTTP Strict Transport Security.

HSTS instructs browsers to enforce HTTPS-only connections for a domain for a specified duration. The preload list extends protection to first-ever visits by hardcoding HSTS policies in browsers.

SSL stripping (Moxie Marlinspike, 2009) downgrades HTTPS to HTTP; HSTS defeats it. Active mixed content (HTTP scripts on HTTPS pages) is blocked by browsers. The upgrade-insecure-requests CSP directive automates HTTP-to-HTTPS migration for legacy content.