This post was co-authored by Adrian Zapletal.
Every time you type a web address, your browser makes a quiet, consequential decision: Should it connect securely over HTTPS, or fall back to plain, unencrypted HTTP? You never see this choice, but an attacker sitting between you and the site you’re visiting can. And for over a decade, that choice has been the soft underbelly of web security.
The current web still relies on a legacy assumption that a website should be accessible over unencrypted HTTP unless it explicitly signals otherwise. However, web users generally want to use HTTPS — the encrypted variant of HTTP — to protect their traffic.
This assumption enables so-called stripping attacks, where an attacker (for example, a compromised ISP router, or a rogue Wi-Fi hotspot) can downgrade a connection to unencrypted HTTP before the browser learns that secure HTTPS is available. The attacker simply blocks the HTTPS handshake, and the user’s web browser falls back to plain HTTP. This hands the attacker an unencrypted session. No keys broken, no certificates forged. From there, they can inject content at will, and read credentials in plaintext. There are client-side security modes and server-side configurations that reduce the risk, but none fully remove the underlying dependency on an opt-in security model.
The long-term objective is to move the web away from this opt-in approach entirely, making encrypted transport the default, and minimizing reliance on website operators to explicitly enable protection.
Why is this challenging?
A core difficulty is compatibility with the heterogeneous nature of the Web. While most public services support HTTPS, a long tail of systems still depend on HTTP for operational, diagnostic, or legacy reasons.
Any proposal that changes browser behaviour must account for these use cases. Strengthening security is relatively easy if compatibility can be ignored. The more difficult problem is finding a path that improves protection without disrupting legitimate services that users still rely on. That is, HTTPS should generally be the default, but there should be exceptions — legitimate services that require HTTP must remain functional.
Another challenge is the trust model for exceptions. If HTTPS is assumed by default, there must be a way to signal legitimate HTTP usage. These signals must be resistant to tampering to prevent attackers from exploiting them.
A secure opt-out model for web security
HTTP Strict Transport Security (HSTS) is an existing mechanism that requires individual websites to declare that they should always be accessed securely, either after a user’s first visit or through inclusion in a preload list. HSTS-Enforced builds on top of HSTS by inverting its security model: Secure transport becomes the baseline assumption, while HTTP becomes the exception that must be explicitly signalled.
The current web’s opt-in model — websites opt into security — flips and becomes an opt-out model. Websites default to security, and opt out if desired.
Two complementary mechanisms are used for explicit and verifiable exception signalling:
- DNS-based declarations protected by DNS Security Extensions (DNSSEC), enabling websites to make authenticated statements that they require HTTP at the domain level.
- A browser-managed preload mechanism for HTTP-required exceptions, similar in operational spirit to existing HSTS preload systems, where the browser contains a list of services known to require HTTP.
Under this model, a browser attempts to establish an HTTPS connection by default. If the connection succeeds, communication proceeds normally. If HTTPS is unavailable, the browser only permits a fallback to HTTP when a trusted indication confirms that the destination intentionally operates without HTTPS support.
The approach effectively shifts the burden of proof. Rather than proving that a site supports HTTPS, operators need to provide evidence that unencrypted transport is genuinely required. This reduces the opportunity for attackers to interfere with the connection, and removes a longstanding weakness in the web’s transport security model.
Key findings and implications
Shifting the default assumption to HTTPS significantly reduces exposure to stripping attacks, particularly during first contact with a domain where current mechanisms are weakest.
The performance impact of HSTS-Enforced is negligible because the change affects decision logic rather than transport overhead. In practice, modern infrastructure already operates predominantly over encrypted channels, making HTTPS default behaviour aligned with real-world usage patterns.
The main operational implication is a redistribution of responsibility. Instead of each service explicitly enabling security protections, secure behaviour becomes the baseline enforced by clients.
Real-world relevance
For browser ecosystems, this model reduces reliance on user-agent heuristics and user discipline, replacing them with deterministic security behaviour.
For most infrastructure operators, it reduces configuration burden associated with enforcing HTTPS policies. For the remainder of the operators, it preserves controlled exceptions where necessary.
For the broader Internet ecosystem, it aligns security guarantees with observed deployment reality: Encrypted transport is already the norm and likewise should be its enforcement.
What’s next
Moving HSTS-Enforced forward depends on coordinated changes across browsers, DNS infrastructure, and standards development.
The rollout of HSTS-Enforced has to be staged. First, introduce a robust, verifiable way for website operators to explicitly signal when encrypted transport cannot be used. Only after that foundation is stable can browsers remove automatic fallbacks to insecure connections and reliance on opt-in security declarations.
While the web is still transitioning toward secure-by-default communication, you can improve your own security today. Enable HTTPS-Only mode in your browser, keep your browser up to date, never ignore certificate warnings, and, if you host a website, enable HTTPS, HSTS preload, and, ideally, DNSSEC.
This post was based on our paper Securing the Web with HSTS-Enforced by Aaron van Diepen, Adrian Zapletal, and Fernando Kuipers (TU Delft). The implementation is released as open-source artifacts.
Aaron van Diepen is conducting PhD research focused on the integration of privacy, security, and ethical principles into the design of next-generation networks.
Adrian Zapletal is a PhD student whose research focuses on fairness and control in the Internet.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.