The Last Mile of HTTPS: Why 27 Million Domains Respond to HTTP but Never Redirect

Q: How do I check if my domain is in the redirect gap?

Run curl -I http://yourdomain.com (substitute your domain). A correct result is a 301 Moved Permanently or 308 Permanent Redirect with a Location header pointing to https://yourdomain.com. A 200 OK response means your domain is in the redirect gap — it is serving content over HTTP without redirecting.

Published 2026-08-20

The Last Mile of HTTPS: Why 27 Million Domains Respond to HTTP but Never Redirect

The August 2026 census, covering 376,928,750 graded domains as of 16 August 2026, surfaces a failure mode that sits between two better-understood problems. It is not the HTTP-only holdout problem examined separately, where 44,443,652 domains (11.8% of the graded set) have no TLS at all. It is something more specific, and in operational terms more frustrating: approximately 27 million domains have a valid TLS certificate, serve HTTPS correctly when asked for it, and still accept and serve plaintext HTTP to any visitor who does not manually prefix their URL with https://.

These domains paid for (or were automatically issued) a certificate. Their servers negotiated TLS handshakes successfully. The encrypted endpoint works. The redirect from port 80 to port 443 does not.

The Finding in Numbers

Of the approximately 231 million domains in the census that have HTTPS available (measured as a valid certificate present, port 443 responsive), approximately 204 million perform the HTTP-to-HTTPS redirect correctly at scan time. That leaves approximately 27 million with a working HTTPS version and an unprotected HTTP entry point that stays open.

These figures are approximate derivations. The census measures redirect behaviour at the moment of the scan, not over time, so a domain that redirects intermittently may appear in either cohort depending on timing. The direction of the finding is not in doubt: tens of millions of production domains have TLS deployed but not enforced.

To be precise about what “not enforced” means here: an HTTP request to port 80 on these domains receives a response, whether that is an HTML page, a login form, an API endpoint, or an administrative interface, without any Location header directing the client to the HTTPS equivalent. The certificate exists. The protection it is supposed to provide does not reach the user unless the user already knows to ask for HTTPS.

What a Correct Configuration Looks Like

RFC 7231 defines the semantics of HTTP redirects. A correct HTTPS enforcement configuration responds to any HTTP request with a 301 Moved Permanently or 308 Permanent Redirect status code, a Location header pointing to the https:// equivalent of the requested URL, and nothing else substantive in the body. Browsers cache 301 responses, which reduces the redirect overhead on repeat visits.

That redirect alone is necessary but not sufficient. A user connecting for the first time over HTTP completes at least one plaintext round trip before the browser knows to switch. The redirect response itself travels over HTTP. An attacker positioned between the client and the server can intercept and modify that response.

HTTP Strict Transport Security, defined in RFC 6797, closes this window for subsequent visits. A correct HSTS deployment sends the Strict-Transport-Security response header on every HTTPS response:

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

Once a browser receives and caches this header, it refuses to connect to the domain over HTTP for the duration of the max-age period. The browser upgrades the request to HTTPS internally, before any network connection is made. There is no plaintext round trip, no redirect to intercept.

The 27 million domains in the redirect gap have neither piece. They skipped the 301 and they skipped the HSTS header. A user who types the domain name into their browser address bar and presses enter, without typing https://, is served over HTTP for as long as that domain remains in this state.

The SSL Stripping Attack

The redirect gap is not a theoretical concern. It is the exact precondition that the SSL stripping attack, demonstrated publicly by Moxie Marlinspike at Black Hat DC 2009, was designed to exploit.

SSL stripping operates as a man-in-the-middle. The attacker intercepts the client’s initial HTTP request before any redirect occurs. The attacker then makes the HTTPS connection to the server themselves, acting as a legitimate HTTPS client, while maintaining the plaintext HTTP connection with the victim. From the server’s perspective, the session is encrypted. From the victim’s perspective, they are browsing HTTP. The browser’s padlock never appears. Credentials, session tokens, and form submissions travel in cleartext from the client to the attacker before being re-encrypted and forwarded to the server.

The attack requires a network position between the client and the server, which is why the threat model matters. Public Wi-Fi, corporate proxy environments, ISP-level interception, and BGP hijacking events all create such positions routinely. The 2018 BGP hijacking of Amazon Route 53, the 2019 events affecting European internet exchange points, and documented cases of ISP-level HTTP injection demonstrate that network-path assumptions do not hold across the open internet.

A domain that performs the 301 redirect gives the attacker a narrow window on the first visit. A domain with HSTS closes that window entirely for repeat visitors. A domain in the redirect gap keeps the window open permanently.

Why HSTS Was Built for This Problem

The HSTS specification, RFC 6797, published in November 2012, opens with an explicit description of the threat it addresses: a passive eavesdropper or active network attacker exploiting the initial cleartext request. The mechanism is deliberately simple. No cryptographic negotiation, no key exchange, no infrastructure dependency beyond the HTTPS connection itself. The browser records the domain, the expiry time, and whether subdomains are included. On subsequent requests, the browser rewrites http:// to https:// before the TCP connection is established.

The current census round finds tens of millions of domains with some HSTS deployment. That number, while large in absolute terms, represents a fraction of the domains with valid TLS. Most of the 27 million in the redirect gap have no HSTS header at all.

The quality of HSTS deployment matters as much as its presence. RFC 6797 recommends a max-age of at least 15,768,000 seconds (six months) for meaningful protection. Short max-age values, below roughly 2,592,000 seconds (30 days), provide limited defence because the protection expires before many users return. HSTS without includeSubDomains leaves subdomains exposed.

The Preload List: Closing the First-Visit Gap

HSTS has one structural limitation: a user who visits a domain for the first time has no cached HSTS record. That first visit remains vulnerable.

The HSTS preload list, maintained at hstspreload.org and incorporated into Chrome, Firefox, Safari, and Edge, solves this by hardcoding HSTS policies for submitted domains into the browser binary itself. A domain on the preload list is treated as HTTPS-only from the very first visit on any browser that ships with the list, before any HTTP connection has ever been made to the domain.

Preload submission requires: a valid max-age of at least 31,536,000 seconds (one year), the includeSubDomains directive, and the preload directive in the HSTS header. The domain and all its subdomains must support HTTPS correctly before submission, because preloading applies to subdomains whether or not they are ready.

The preload list is the complete solution to the first-visit problem. It is also a commitment: removal from the list takes months and requires browsers to ship an update. Operators should not submit domains whose subdomain HTTPS coverage is incomplete.

How Domains End Up in the Redirect Gap

The redirect gap is not populated by malice. The common causes fall into a small number of patterns.

Staging configurations promoted to production. Development and staging environments frequently disable HTTPS redirects for convenience. When a deployment pipeline promotes configuration from staging to production without an environment-specific override, the redirect is absent in production too.

Load balancer or reverse proxy misconfiguration. In many architectures, TLS terminates at a load balancer, and the origin server receives all traffic as HTTP. The redirect must be configured at the load balancer layer, not the application layer. It is common to configure TLS termination correctly and omit the HTTP listener and redirect rule entirely.

Platform defaults that favour compatibility. Shared hosting panels and some CDN configurations default to accepting HTTP to avoid breaking customer sites during onboarding. The operator enables the TLS certificate but does not locate or enable the separate “force HTTPS” setting.

Legacy applications. Applications that construct absolute internal URLs using http:// schemes break when an unconditional redirect is applied. Operators sometimes disable the redirect to avoid the breakage rather than fixing the URL generation.

What to Check and Fix

Nginx: A dedicated server block listening on port 80 containing only the redirect:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

On the HTTPS server block, add the HSTS header at a max-age appropriate for the deployment’s maturity. Start at 300 seconds during testing, increase to 63,072,000 (two years) once stable.

Apache:

<VirtualHost *:80>
    ServerName example.com
    Redirect permanent / https://example.com/
</VirtualHost>

Add Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains" to the HTTPS virtual host.

Caddy: Performs the HTTP-to-HTTPS redirect automatically for any site with a configured TLS certificate. Verify that auto_https has not been disabled in the global options block.

AWS Application Load Balancer: Create an HTTP listener on port 80 with a “Redirect to HTTPS” action. Set the status code to 301.

Cloudflare: Enable “Always Use HTTPS” in the SSL/TLS settings. Set HSTS via the dedicated HSTS settings panel.

Verification: After any change, test with curl:

curl -I http://example.com

The response should be a 301 or 308 with a Location header pointing to https://example.com. A 200 response indicates the redirect is not in place.

Regulatory Context

GDPR Article 32 requires “appropriate technical and organisational measures” to ensure security of processing appropriate to the risk. Transmitting personal data over unencrypted HTTP while a working HTTPS endpoint exists on the same server is difficult to defend as appropriate to any risk level. NCSC TLS guidance and German BSI TR-03116 both cite encrypted transport as a baseline control.

RFC 2818, which defines HTTP over TLS, predates these regulatory frameworks. The technical requirement has been settled for over two decades. The approximately 27 million domains in the redirect gap are not waiting on a standards process. They are waiting on a configuration change.

The Operational Summary

A domain with a valid TLS certificate and a functioning HTTPS version has already absorbed the cost of HTTPS. The protection that expenditure was meant to deliver is conditional on the user knowing to request https://. Most users do not type the scheme. Most browsers, absent a preload entry or a cached HSTS record, will attempt http:// first.

The redirect and the HSTS header convert a conditional guarantee into an unconditional one. Both are zero-cost in terms of infrastructure. Both are available in every web server, load balancer, and CDN in common use. The census finding of approximately 27 million domains in the redirect gap describes not a resource problem but a configuration problem that can be closed, in most environments, in under ten minutes.

Check your domain’s HTTPS redirect and HSTS configuration against the August 2026 census baseline.

Data source: defaults.exposed August 2026 census, methodology v9, as of 16 August 2026, covering 376,928,750 graded domains. Redirect behaviour is measured at scan time; intermittent configurations may appear in either cohort. Figures for the redirect gap are approximations derived from census check columns. References: RFC 6797 (HSTS), RFC 7231 (HTTP redirect semantics), RFC 2818 (HTTP over TLS), hstspreload.org, GDPR Article 32, NCSC TLS guidance.

What this means

For web developers and DevOps teams, the redirect gap finding has a direct diagnostic implication: if your domain has a TLS certificate but you have not explicitly verified the HTTP-to-HTTPS redirect with a tool like curl, you may be in this cohort. The gap is almost never intentional — it arises from staging configurations promoted without environment overrides, load balancer setups where TLS terminates upstream, or platform onboarding flows that install a certificate without enabling forced HTTPS. Checking takes one command. Fixing takes under ten minutes on any major web server or CDN.

For IT managers and security leads, the regulatory dimension of this finding is concrete. GDPR Article 32 requires appropriate technical measures for personal data processing. A login form, customer portal, or contact form served over unencrypted HTTP on a domain that has a working HTTPS endpoint is not a theoretical gap — it is a data protection gap that regulators and auditors increasingly flag. The certificate was already purchased. The redirect and HSTS header are free. The organisation is one configuration change from compliance on this specific point.

For small business owners with websites, the practical message is: having a padlock on your website is not enough if users can reach it without the padlock. Most people type domain names without typing https:// first. If your server responds to HTTP requests with content rather than a redirect, those visitors are unprotected until they click through or are redirected. Check your site with curl -I http://yourdomain.com — a 301 response is what you want; a 200 response means you are in the redirect gap.

Data to cite

“Approximately 27 million domains have valid TLS certificates and working HTTPS but still accept and serve plaintext HTTP with no redirect — leaving every visitor who types the domain without ‘https://’ exposed to SSL stripping.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“44,443,652 domains — 11.8% of the 376.9M graded — have no TLS at all, while an additional ~27 million have TLS but fail to enforce it via HTTP redirect, representing two distinct HTTPS failure modes.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“Of approximately 231 million domains with HTTPS available, approximately 204 million perform the HTTP-to-HTTPS redirect correctly — leaving roughly 27 million with an open plaintext entry point despite a working encrypted endpoint.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“The redirect gap is the exact precondition for SSL stripping, first demonstrated at Black Hat DC 2009: an attacker on the network path intercepts the initial HTTP request before any redirect, maintaining plaintext visibility of the session while the server believes the connection is encrypted.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“HSTS (RFC 6797) closes the redirect gap for repeat visitors by instructing browsers to upgrade requests to HTTPS before any network connection is made — but most of the 27 million redirect-gap domains have no HSTS header at all.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“The configuration fix for the redirect gap — a 301 redirect rule and an HSTS response header — is available in every web server, load balancer, and CDN in common use, costs nothing, and takes under ten minutes to deploy.” — defaults.exposed August 2026 Domain Security Census (432M domains)

FAQ

What is the redirect gap and why does it matter? The redirect gap describes domains that have a valid TLS certificate and a working HTTPS endpoint, but still respond to plain HTTP requests with content rather than a redirect. This means any visitor who types the domain name without https:// — which is most users, most of the time — receives an unencrypted connection. The gap is the exact setup that SSL stripping attacks exploit: an attacker on the network path intercepts the HTTP request before any redirect occurs and maintains a plaintext view of the session.

My site has a padlock. Isn’t that enough? Only if the user reaches your site over HTTPS. If your server responds to HTTP requests with a 200 OK rather than a 301 Moved Permanently, users who type your domain without https:// are served over HTTP. Most browsers attempt http:// by default when no scheme is typed. A padlock that only appears if the user already knows to ask for HTTPS does not protect the users who don’t know.

What is HSTS and do I need it? HSTS (HTTP Strict Transport Security, RFC 6797) is a response header that tells browsers to refuse plain HTTP connections to your domain for a specified period — even on the first request, once cached. Without HSTS, a redirect alone still leaves the initial connection vulnerable (the redirect response itself travels over HTTP and can be intercepted). With HSTS, the browser upgrades the request to HTTPS before any network connection is made, closing the first-visit gap. You need both the redirect and HSTS for complete protection.

How do I check if my domain is in the redirect gap? Run curl -I http://yourdomain.com (substitute your domain). A correct result is a 301 Moved Permanently or 308 Permanent Redirect with a Location header pointing to https://yourdomain.com. A 200 OK response means your domain is in the redirect gap — it is serving content over HTTP without redirecting.

Is this a GDPR issue? Potentially, yes. GDPR Article 32 requires appropriate technical measures for personal data processing. A contact form, login page, or customer portal served over unencrypted HTTP on a domain with a working HTTPS endpoint is difficult to defend as an appropriate security measure. Regulators and auditors increasingly treat missing HTTP-to-HTTPS redirects as a findable gap, not just a best-practice recommendation.

How does the redirect gap compare between August 2026 and July 2026? The approximately 27 million figure is derived from the August 2026 census (asOf 2026-08-16, 376,928,750 graded domains). The redirect gap is a recurring measurement; the absolute number may shift between rounds as new certificates are issued and configurations change. The structural finding — tens of millions of production domains with TLS deployed but not enforced — is consistent across rounds.

Can this be fixed without touching my application code? In most cases, yes. The redirect and HSTS header are configured at the web server, load balancer, or CDN layer, not in application code. Nginx, Apache, Caddy, AWS ALB, and Cloudflare all support this configuration through their own settings panels or configuration files, as shown in the fix section above. The only case where application involvement is needed is if your application generates absolute http:// URLs that break under a redirect — a separate issue worth fixing regardless.

Check your domain free at defaults.exposed — verify whether your domain correctly redirects HTTP to HTTPS and has HSTS deployed, and see exactly which of the redirect and HSTS checks you pass or fail. Takes 30 seconds. No account needed.

Aggregate data only. Data stored and processed in the EU.

How to cite this report

Press / blog: defaults.exposed (2026). The Last Mile of HTTPS: Why 27 Million Domains Respond to HTTP but Never Redirect. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/redirect-gap-https-no-enforcement-2026

Academic: defaults.exposed. (2026, August 20). The Last Mile of HTTPS: Why 27 Million Domains Respond to HTTP but Never Redirect. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/redirect-gap-https-no-enforcement-2026

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=376,928,750; redirect-gap ~27M)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,781 of them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/en/articles/domain-security-scoring-methodology-v9 Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026