Encryption over HTTPS solves many problems, but one element has remained a critical vulnerability point for years: the moment when the browser still does not yet know whether it should use HTTPS. This stage precedes the actual TLS connection. It happens before the handshake is performed, before the certificate is verified and before the server even gets the opportunity to enforce any rules. It is exactly in this time window that room appears for SSL stripping, for traffic manipulation in a public network and for attacks that rely on intercepting the first request and modifying the response so that the user never reaches the encrypted version.
HSTS and HSTS Preload: how does the browser make trust decisions before it establishes a connection?
The HSTS mechanism was designed as a component that allows the browser to remember that a given domain must be served exclusively over HTTPS. However, this information reaches the browser only when the server returns the appropriate header, which means after the first connection. If that first connection is compromised, the HSTS policy may never be delivered, because the attacker can easily remove or replace it. This means that the basic HSTS model works very well, but only if the user has already had a chance to visit the site in safe conditions at least once. HSTS Preload removes this problem completely. The preload list is embedded in the browser code. It literally resides in the Chrome build structure and is synchronized to other browsers. When the user enters the address of a preloaded domain, the browser does not ask any questions: it does not connect over HTTP, it does not allow a connection on port 80, it does not wait for a server header. It simply routes traffic exclusively over HTTPS from the outset. In practice, it looks as if the entire domain has been moved into a different, harder trust model, the only one in which it is not possible to fool the browser by manipulating the first packet.
This can be easily observed by comparing the behavior of the browser with and without preload. In a domain without preload, the browser will perform an actual HTTP request before receiving the 301 redirect:
GET / HTTP/1.1
Host: example.pl
In a preloaded domain, there is not even a TCP connection to port 80. The browser rewrites the address internally before the network layer:
https://example.pl
This step is invisible to the user, but it is fundamental. The entire first phase of communication, which was the most sensitive to manipulation, ceases to exist. This is exactly why preload is treated as a serious technological declaration: it cannot be withdrawn instantly, it cannot be bypassed and its consequences are global. The technical requirements follow directly from this trust model. Browsers cannot allow a situation in which a preloaded domain has even a single subdomain running on HTTP or even a single endpoint that does not support a certificate. This is why three elements are required: max-age of at least one year, includeSubDomains and the preload keyword. The header must be constructed as follows:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
If a domain uses Cloudflare, the header can be set without even touching the origin, directly in transform rules or in the SSL → HSTS panel. For servers such as NGINX or OpenLiteSpeed, configuration is also straightforward:
NGINX:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
OpenLiteSpeed (vhost-level rule):
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
The biggest mistake administrators make is assuming that HSTS is only about a single header. In reality, it is a decision that affects the entire architecture of the domain. If the structure includes an unused subdomain, a test environment on HTTP, an old admin panel or anything that does not meet HTTPS requirements, preload disqualifies it. This is why many commercial companies consciously decide not to use it, even though they know that the solution is ideal from a security perspective. Preload does not tolerate gaps in organizational discipline. It is also worth noting that preload fits perfectly with the modern model of traffic through a CDN. When TLS is terminated at the edge, for example in Cloudflare, the CDN becomes the “server” for the browser. If preload is active, the entire communication model is deterministic and consistent, regardless of which POP the browser ends its routing on. This is one of the reasons why preloaded domains more often achieve a stable A+ rating in SSL Labs at all points of presence.
Enabling preload is therefore a decision that changes the nature of a domain from “HTTPS optional” to “HTTPS compulsory”. This is not a simple act of turning on a header. In practice, it closes all possible ways back and is an unambiguous statement: “this domain will never again operate over HTTP”. For companies that build security products, such as HEXSSL, this is a natural step, because preload emphasizes consistency and discipline in the design of the transport architecture.
What if something goes wrong? Preload as a decision that is difficult to reverse.
Preload is one of the few security mechanisms that does not operate in real time but is based on the software life cycle. When a domain is added to the preload list, browsers retrieve this information as part of updates and store it for the entire lifetime of the installed version. This means that even if you later remove the preload directive from the header, clients will still treat your domain as HTTPS only until they install a new version of the browser. If a user relies on a system where updates are rare (for example Android from 2018), the change may not reach them for many years.
For this reason, the process of removing a domain from preload is slow and propagation time depends on millions of individual factors. Google requires administrators to request removal from the preload list only in justified situations, ones where the security configuration has been compromised in a serious and lasting way. In practice, this means the need to publish a temporary header that disables the policy and allows browsers to use HTTP again. However, browsers that still have an old version of the preload list will continue to enforce HTTPS. As a result, preload behaves less like a configuration setting and more like an architectural declaration. There are very few domains that have been removed from the preload list, precisely because the procedure is neither quick nor painless. Every organization that wants to submit a domain should fully understand that preload cements the communication model for years and that there is no way to perform an immediate rollback.
The most common administrator mistakes: when a domain violates its own security policy.
Although preload is simple at the technical layer, the mistakes administrators make are often subtle and difficult to detect without proper tools. The most common problem is subdomains that exist outside the awareness of the team, such as staging environments left in the cloud, test developer panels, unused wildcards or integrations that have long lost relevance but still exist in DNS. If even one such endpoint operates only over HTTP, the preload policy is violated, although the domain owner may not even know that the problem exists.
Another typical mistake is the use of temporary environments for testing that are exposed publicly and then forgotten. Tools such as CertSpotter, crt.sh or DNS scanners sometimes reveal hundreds of certificates issued for subdomains that administrators no longer remember. If the includeSubDomains policy is active, each such subdomain is treated as a security commitment. Many problems also result from inconsistent behavior between the origin and the CDN. If the CDN returns a correct HSTS header but the origin does not, a discrepancy appears. The browser sees traffic only through the CDN, but automated mechanisms, such as compliance scanners, may detect differences between infrastructure layers. In extreme cases, incorrect headers on the origin are interpreted as an attempt to reduce the security level, which can cause the preload submission to be rejected.
These issues do not arise from bad intentions but from the natural complexity of large DNS structures and hundreds of access points. This is exactly why a subdomain audit and full observability of the transport layer are essential before any decision about preload. Tools such as curl, openssl s_client and dedicated audit scripts make it possible to detect inconsistencies that would normally remain invisible.
How does the browser enforce the HSTS Preload policy? The internal Chrome mechanism.
Although HSTS Preload looks like a simple list of domains from the outside, its implementation inside the browser is more complex. Chrome compiles a static JSON file into a C++ structure that is loaded during application startup. Each entry contains a data area that stores security attributes, policy flags and information about the need to enforce HTTPS. When a user enters a domain name, Chrome does not yet perform any network request. The first stage takes place in the URLLoader layer: before a TCP socket is initialized, Chrome checks the local HSTS policy. If the domain is on the preload list, the browser modifies the protocol scheme to https:// and starts the TLS handshake, skipping the entire HTTP process. In the source code, it looks approximately like this:
if (IsPreloadedHSTS(host)) {
scheme = "https";
}
Only after entering the HTTPS branch does Chrome move to the net/socket layer and attempt to establish a connection to port 443. If the server does not support HTTPS, communication immediately ends with an error and the user sees a message that the connection cannot be established, even if the server technically operates over HTTP. This behavior is fully intentional: preload blocks any possibility of falling back to unencrypted communication. The entire process works locally, deterministically and independently of network configuration. An attacker has no leverage point in this mechanism, because they cannot influence the data the browser uses before a connection is established. That is exactly why preload is one of the most effective protective mechanisms in the history of web security.
The full migration path of an organization to preload: a process that must cover the entire domain.
Migrating to HSTS Preload requires an approach that is closer to deploying an architecture than to setting a single header. Preload does not forgive half measures. It enforces full transport discipline. The first step is to obtain complete visibility of the DNS space, because preload covers absolutely all subdomains and many organizations have historical DNS records that no one remembers anymore. This is the stage where broad enumeration, certificate scanners and access tools are used to identify a complete map of points that will be subject to the policy.
A typical control begins with a certificate dump from crt.sh:
curl -s "https://crt.sh/?q=%.example.com&output=json"
This is not a list of certificates, but a list of real, active traces of subdomains, many of which may have been abandoned. Preload will enforce HTTPS only handling for them, so they must be cleaned up.
The second important stage is consistent behavior across the entire infrastructure. The origin, CDN, load balancer and reverse proxy all have to return a unified policy. In practice, this means adjustments to headers, redirects and TLS configuration at each layer. If, for example, the CDN sends a correct header but the origin does not, a discrepancy appears that may invalidate the preload submission or lead to incorrect interpretations by audit tools.
The HSTS configuration itself also has to match the future policy. During the transition period, organizations most often use the following version of the header:
Strict-Transport-Security: max-age=31536000; includeSubDomains
The preload keyword is added only when the stability of the entire environment is beyond doubt. This observation period usually lasts a few weeks. It is the only way to ensure that applications, integrations, legacy APIs and partner systems operate correctly under enforced HTTPS.
Only after completing:
- full subdomain enumeration,
- harmonization of behavior across all network layers,
- a period of operational stability,
can a domain be submitted to HSTS Preload.
This is not a configuration action. It is an architectural decision to permanently move the entire domain into a security model without communication gaps.
How does preload affect HTTP/3 and QUIC? New transport requires new security logic.
HTTP/3 and QUIC change the way the browser communicates with the server. QUIC operates only over UDP and combines the transport handshake with the cryptographic one. There is no place for unencrypted connections in it, so preload naturally becomes part of the mechanism that decides whether the browser can even try to use QUIC.
For preloaded domains, the behavior is unambiguous: the browser does not consider HTTP as an alternative. It immediately initiates a QUIC handshake and if that fails, it falls back to TLS 1.3 over TCP, but still without allowing HTTP traffic. The protocol selection mechanism stops being heuristic and becomes deterministic. Chrome does not try to guess whether the server supports QUIC. It attempts it immediately, because the preload policy leaves no room for unencrypted layers.
This can be seen in the structure of the first QUIC packet, which combines the ClientHello function with the transport part:
QUIC Initial Packet:
- TLS ClientHello
- Supported Versions: h3, h3-29, h3-27
- ALPN: h3
If a domain is preloaded, the browser moves to this step regardless of network conditions. An attacker cannot force an earlier HTTP connection, because preload blocks any attempt to open port 80 before the network layer. This also affects performance. In the classic model without preload, the browser had to analyze a set of heuristic information such as visit history, previously used protocols, past QUIC errors and network characteristics in order to decide whether it was worth attempting HTTP/3. With preload, the logic is simplified: QUIC is the first choice and fallback is used only if the server truly does not offer HTTP/3.
Preload and QUIC reinforce each other. QUIC removes the cost of TCP plus TLS. Preload removes the entire category of unencrypted transport. Together, they create a model where there is no room for manipulation of the first packets and the entire connection establishment process is both more secure and faster. For globally operating domains such as HEXSSL, this synergy is significant: every CDN POP operates under an identical security model and a user on any continent experiences predictable transport behavior without downgrade risk or network side manipulation.
HEXSSL – HSTS & Preload Checklist.
1. Certificates and domains.
❑ The main domain has a valid certificate
❑ All subdomains have valid certificates
❑ No subdomains without HTTPS
❑ The wildcard covers what it should (and the rest has single certificates)
❑ No DEV or OLD environments are publicly available over HTTP
2. Enforcing HTTPS.
❑ HTTP always returns 301 to HTTPS
❑ 301 is configured at the server level, not in PHP
❑ No HTTP 200/403/404 responses at all
❑ HTTP 301 also returns the HSTS header (according to the RFC)
3. HSTS header correctness.
❑ The header is returned for every HTTPS response
❑ The header has exactly this value: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
❑ max-age ≥ 31536000
❑ includeSubDomains is present
❑ preload is present
❑ “always” or “set” forces the header also on 3xx/4xx/5xx errors
4. Validation tests.
❑ curl -I https://domena | grep -i strict returns the header
❑ curl -I http://domena → 301 + HSTS
❑ curl -I https://www.domena → HSTS
❑ curl -I https://sub.domena → HSTS
❑ Zero HTTP responses (without 301)
❑ Cloudflare (or another provider) does not overwrite the header with incorrect values
5. Subdomains – full validation.
❑ List of subdomains fetched from CT Logs:
curl -s "https://crt.sh/?q=%.domena.com&output=json" | jq '.[].name_value' | sort -u
❑ Each subdomain has a certificate
❑ Each subdomain returns HSTS
❑ Each subdomain enforces HTTPS with 301
❑ No “dead” subdomains with a certificate but without a server
6. Cloudflare / CDN.
❑ SSL Mode: Full (strict)
❑ Minimum TLS: 1.2 or 1.3
❑ HSTS enabled in the CF panel (if used)
❑ No Transform Rule overwrites HSTS with an incorrect value
❑ No Page Rules that could serve HTTP
7. Preload – conditions to meet.
❑ HSTS enabled with max-age ≥ 31536000
❑ includeSubDomains present
❑ preload present
❑ All subdomains respond over HTTPS
❑ No 403/404 errors for critical resources
❑ HTTP never returns content
8. Preload – submission.
❑ Go to: https://hstspreload.org
❑ The test passes 100 percent
❑ Domain submitted
❑ Monitoring of the status in the Chrome Preload List
❑ Internal communication: “operation NOT REVERSIBLE in the short term”
9. Monitoring after deployment.
❑ curl tests every day for 7 days
❑ SSL Labs test after deployment
❑ Alerts on HTTP errors → 301 → HTTPS
❑ Alert for missing HSTS header
❑ Alert for certificate change (CT Monitoring)
❑ Verification that QUIC and H3 work correctly
10. Risk points (what can break preload).
❑ Forgotten subdomain with the server turned off
❑ DEV or OLD subdomain left in DNS
❑ Moving a product to a new server without a certificate
❑ Cloudflare in DNS only mode
❑ Accidental HTTPS deactivation
❑ Incorrect wildcard (for example *.example.com does not cover example.com)
11. Minimal test list before submission.
❑ main domain – HSTS
❑ www – HSTS
❑ wildcard – HSTS
❑ all A and CNAME records from DNS – HTTPS only
❑ 100 percent certificates OK
❑ 0 HTTP pages
❑ 0 Mixed Content errors
❑ 0 errors in the preload validator