pith. sign in

arxiv: 2605.04642 · v1 · pith:5Q2ECPCInew · submitted 2026-05-06 · 💻 cs.CR · cs.NI

Securing the Web with HSTS-Enforced

Aaron van Diepen , Adrian Zapletal , Fernando Kuipers This is my paper

Pith reviewed 2026-05-08 17:33 UTC · model grok-4.3

classification 💻 cs.CR cs.NI
keywords HSTSTLS strippingHTTPS enforcementweb securityDNS recordspreload liststransport security
0
0 comments X

The pith

HSTS-Enforced defaults all web connections to HTTPS and requires explicit indicators for any site that must use HTTP.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

This paper introduces a new approach to web security that addresses TLS stripping attacks by reversing the current opt-in model for HTTPS. Instead of operators having to configure HSTS to force secure connections, all traffic defaults to HTTPS unless an operator signals that HTTP is required. The proposal uses two new HTTP-Required indicators: a DNS record and a preload list entry. Evaluation shows this blocks all practical stripping attempts, keeps HTTP sites accessible, and adds no overhead for standard HTTPS sites. A transition plan is outlined to encourage adoption.

Core claim

HSTS-Enforced flips the security model from opt-in to opt-out: all connections default to HTTPS, and operators can explicitly opt out using HTTP-Required indicators if their websites require HTTP. This eliminates the remaining attack surface for TLS stripping while maintaining backward compatibility and avoiding the limitations and misconfiguration risks of existing mechanisms.

What carries the argument

The HSTS-Enforced mechanism using HTTP-Required indicators, specifically a new DNS record and an HTTP-Required Preload list, to specify exceptions to the default HTTPS policy.

If this is right

  • All practical TLS stripping attempts are blocked.
  • Compatibility is maintained for sites that require HTTP access.
  • No overhead is introduced in the typical case of HTTPS-only sites.
  • A practical transition path accelerates global adoption.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Browser and DNS resolver support for the new indicators would be necessary for full effectiveness.
  • The approach might reduce reliance on individual HSTS header configurations by site operators.
  • Potential interactions with existing preload lists and DNS security extensions could be explored in future deployments.

Load-bearing premise

Browsers, DNS resolvers, and site operators will correctly implement and use the proposed HTTP-Required indicators without widespread misconfiguration or adoption failures.

What would settle it

Demonstrating a successful TLS stripping attack on a properly configured HSTS-Enforced site without an HTTP-Required indicator would show the claim is incorrect.

Figures

Figures reproduced from arXiv: 2605.04642 by Aaron van Diepen, Adrian Zapletal, Fernando Kuipers.

Figure 1
Figure 1. Figure 1: The process of checking whether HSTS is enabled for view at source ↗
Figure 3
Figure 3. Figure 3: The connection process with HSTS-Enforced when view at source ↗
Figure 4
Figure 4. Figure 4: Packet sizes of DNS records used during resolution of view at source ↗
Figure 5
Figure 5. Figure 5: Resolution times for verifying the HTTPREQ record, view at source ↗
read the original abstract

TLS stripping attacks expose sensitive web traffic by forcing secure HTTPS connections to fall back to unencrypted HTTP. At present, protection against these attacks relies on website operators explicitly opting into security by deploying mechanisms such as HTTP Strict Transport Security (HSTS) headers. These mechanisms have significant limitations: some are weak or difficult to configure, which raises the risk of misconfiguration and reduces practical adoption; others violate HTTP backward compatibility; at least one can even be abused to enable unintended user tracking. We introduce HSTS-Enforced, a mechanism that eliminates the remaining attack surface for TLS stripping while still allowing operators to securely specify that their websites need to be accessed over HTTP when necessary, thereby maintaining accessibility. To achieve this, we flip the current opt-in security model to an opt-out model: all connections default to HTTPS, and operators can explicitly opt out if their websites require HTTP using so-called HTTP-Required indicators. We propose two such HTTP-Required indicators: a new DNS record and an HTTP-Required Preload list. We evaluate HSTS-Enforced under multiple deployment scenarios, demonstrating that it blocks all practical TLS stripping attempts while maintaining compatibility for sites that require HTTP - without introducing overhead in the typical case. Finally, we outline a practical transition path to accelerate global adoption.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The paper proposes HSTS-Enforced, which inverts the current opt-in model for HTTPS protection against TLS stripping: all connections default to HTTPS, and operators may explicitly opt out for HTTP-required sites via two proposed 'HTTP-Required' indicators (a new DNS record or a preload list). It claims this blocks all practical TLS stripping attacks while preserving backward compatibility for HTTP sites and introducing no overhead in the common case, supported by evaluations across deployment scenarios plus a transition plan.

Significance. If the security and compatibility claims hold, the work would meaningfully advance web transport security by reducing reliance on voluntary HSTS deployment and closing a long-standing attack surface for on-path stripping, with potential for high impact given the scale of web traffic.

major comments (2)
  1. [DNS record mechanism] The DNS-based HTTP-Required indicator (described in the mechanism proposal) can be spoofed by an on-path attacker via unauthenticated DNS responses, which is a standard vector in TLS-stripping scenarios. This directly contradicts the central claim that the scheme 'blocks all practical TLS stripping attempts,' as the attacker can force an HTTP fallback for sites that do not publish the record. The preload-list alternative avoids this, but the DNS path remains part of the design.
  2. [Evaluation and deployment scenarios] The evaluation (referenced in the abstract and transition discussion) asserts complete blocking of practical attacks, compatibility maintenance, and zero typical-case overhead, yet supplies no quantitative metrics, attack traces, implementation details, or comparative measurements against existing HSTS variants to support these assertions.
minor comments (1)
  1. [Abstract] The abstract and introduction use the phrase 'all practical TLS stripping attempts' without defining the threat model boundary (e.g., whether it includes DNS spoofing or only passive stripping).

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for their thorough and constructive review of our manuscript. We address each major comment point by point below, providing clarifications and committing to revisions where appropriate to strengthen the paper.

read point-by-point responses

  1. Referee: [DNS record mechanism] The DNS-based HTTP-Required indicator (described in the mechanism proposal) can be spoofed by an on-path attacker via unauthenticated DNS responses, which is a standard vector in TLS-stripping scenarios. This directly contradicts the central claim that the scheme 'blocks all practical TLS stripping attempts,' as the attacker can force an HTTP fallback for sites that do not publish the record. The preload-list alternative avoids this, but the DNS path remains part of the design.

    Authors: We acknowledge the validity of this observation. The DNS-based HTTP-Required indicator does rely on unauthenticated DNS responses and is therefore vulnerable to spoofing by an on-path attacker, who could inject a false record to force an HTTP fallback even for sites that do not publish the indicator. This does limit the security of the DNS variant and requires adjustment to our broader claims. The preload-list alternative remains unaffected, as it draws from a trusted centralized source. In the revised manuscript, we will reposition the DNS record as a lightweight, decentralized option with explicit limitations (analogous to other unauthenticated DNS records), strongly recommend the preload list for security-critical use, and revise the abstract, introduction, and claims to state that the scheme blocks all practical TLS stripping attempts when the preload list is used (or when DNS records are protected by DNSSEC). We will also add an explicit discussion of this spoofing vector and the resulting trade-offs. revision: yes

  2. Referee: [Evaluation and deployment scenarios] The evaluation (referenced in the abstract and transition discussion) asserts complete blocking of practical attacks, compatibility maintenance, and zero typical-case overhead, yet supplies no quantitative metrics, attack traces, implementation details, or comparative measurements against existing HSTS variants to support these assertions.

    Authors: We agree that the evaluation would be strengthened by additional concrete evidence. The current manuscript presents a qualitative analysis of deployment scenarios to illustrate attack blocking, compatibility preservation, and typical-case overhead, but it does not include quantitative metrics, attack traces, prototype implementation details, or direct comparisons with HSTS variants. In the revised version, we will expand the evaluation section to incorporate: a description of a reference prototype implementation; sample attack traces demonstrating blocked stripping attempts across scenarios; performance measurements confirming negligible overhead in the common case; and comparative analysis against standard HSTS and related mechanisms. These additions will provide the empirical support for the stated properties. revision: yes

Circularity Check

0 steps flagged

No circularity: forward-looking design proposal with no self-referential derivations

full rationale

The manuscript introduces HSTS-Enforced as an opt-out security model that defaults to HTTPS and permits explicit HTTP-Required indicators (new DNS record or preload list). No equations, fitted parameters, or predictive derivations appear in the provided text. Claims about blocking TLS stripping and maintaining compatibility rest on deployment assumptions and standard security primitives rather than reducing to self-definitions, self-citations, or renamed inputs. The evaluation under scenarios is descriptive, not a closed loop of fitted predictions. This matches the expected non-circular outcome for a new mechanism proposal.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 2 invented entities

The proposal rests on deployment assumptions about client and operator behavior rather than new mathematical entities or fitted constants.

axioms (2)
  • domain assumption Browsers and DNS infrastructure will enforce the new default HTTPS behavior and correctly interpret HTTP-Required indicators.
    Central to the security guarantee; appears in the transition and evaluation description.
  • domain assumption Site operators will accurately identify and mark sites that genuinely require HTTP access.
    Necessary to avoid breaking legitimate HTTP-only sites.
invented entities (2)
  • HTTP-Required DNS record no independent evidence
    purpose: Indicator allowing a domain to declare it must be accessed over HTTP.
    New record type proposed to support the opt-out model.
  • HTTP-Required Preload list no independent evidence
    purpose: Central registry of sites that require HTTP access, analogous to HSTS preload.
    New list mechanism to bootstrap the opt-out for high-traffic sites.

pith-pipeline@v0.9.0 · 5522 in / 1300 out tokens · 60552 ms · 2026-05-08T17:33:04.592632+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

56 extracted references · 56 canonical work pages

  1. [1]

    HTTP Over TLS

    E. Rescorla, “HTTP Over TLS.” RFC 2818, 2000

    work page 2000

  2. [2]

    HTTP Strict Transport Security (HSTS)

    J. Hodges, C. Jackson, and A. Barth, “HTTP Strict Transport Security (HSTS).” RFC 6797, 2012

    work page 2012

  3. [3]

    New Tricks for Defeating SSL in Practice

    M. Marlinspike, “New Tricks for Defeating SSL in Practice.” Black Hat DC. https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/ BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf, 2009

    work page 2009

  4. [4]

    More Tricks for Defeating SSL in Practice

    M. Marlinspike, “More Tricks for Defeating SSL in Practice.” Black Hat USA. https://www.blackhat.com/presentations/bh-dc-09/ Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf, 2009

    work page 2009

  5. [5]

    HSTS Preload List Submission

    The Chromium Authors, “HSTS Preload List Submission.” HSTS Preload List Submission. https://hstspreload.org/, 2012

    work page 2012

  6. [6]

    Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records

    B. M. Schwartz, M. Bishop, and E. Nygren, “Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records.” RFC 9460, 2023

    work page 2023

  7. [7]

    HTTPS-First Upgrades to Secure Connections

    Mozilla Support Community, “HTTPS-First Upgrades to Secure Connections.” Mozilla Support. https://support.mozilla.org/en-US/kb/ https-first, 2025

    work page 2025

  8. [8]

    HTTPS-Only Mode in Firefox

    Mozilla Support Community, “HTTPS-Only Mode in Firefox.” Mozilla Support. https://support.mozilla.org/en-US/kb/https-only-prefs, 2025

    work page 2025

  9. [9]

    Mission Accomplished? HTTPS Security after DigiNotar,

    J. Amann, O. Gasser, Q. Scheitle, L. Brent, G. Carle, and R. Holz, “Mission Accomplished? HTTPS Security after DigiNotar,” inACM IMC, 2017

    work page 2017

  10. [10]

    Measuring the Rapid Growth of HSTS and HPKP Deployments,

    I. S. Petrov, D. I. Peskov, G. Coard, T. Chung, D. R. Choffnes, D. Levin, B. M. Maggs, A. Mislove, and C. Wilson, “Measuring the Rapid Growth of HSTS and HPKP Deployments,” inIET CANS, 2017

    work page 2017

  11. [11]

    The Security Lottery: Measuring Client-Side Web Security Inconsistencies,

    S. Roth, S. Calzavara, M. Wilhelm, A. Rabitti, and B. Stock, “The Security Lottery: Measuring Client-Side Web Security Inconsistencies,” inUSENIX Security, 2022

    work page 2022

  12. [12]

    On the Security of Parsing Security-Relevant HTTP Headers in Modern Browsers,

    H. Siewert, M. Kretschmer, M. Niemietz, and J. Somorovsky, “On the Security of Parsing Security-Relevant HTTP Headers in Modern Browsers,” inIEEE S&P Workshops, 2022

    work page 2022

  13. [13]

    Analysis of the Adoption of Security Headers in HTTP,

    W. Buchanan, S. Helme, and A. Woodward, “Analysis of the Adoption of Security Headers in HTTP,”IET Information Security, vol. 12, no. 2, 2017

    work page 2017

  14. [14]

    HTTP Security Headers Analysis of Top One Million Websites,

    A. Lavrenovs and F. J. R. Mel ´on, “HTTP Security Headers Analysis of Top One Million Websites,” inInternational Conference on Cyber Conflict (CyCon), 2018

    work page 2018

  15. [15]

    Uncovering HTTP Header Inconsistencies and the Impact on Desktop/Mobile Websites,

    A. Mendoza, P. Chinprutthiwong, and G. Gu, “Uncovering HTTP Header Inconsistencies and the Impact on Desktop/Mobile Websites,” inACM WWW, 2018

    work page 2018

  16. [16]

    Analysing HSTS and HPKP Implemen- tation in Both Browsers and Servers,

    S. de los Santos and J. Torres, “Analysing HSTS and HPKP Implemen- tation in Both Browsers and Servers,”IET Information Security, vol. 12, no. 4, 2018

    work page 2018

  17. [17]

    HSTS Supports Targeted Surveillance,

    P. Syverson and M. Traudt, “HSTS Supports Targeted Surveillance,” in USENIX FOCI, 2018

    work page 2018

  18. [18]

    Chromium

    The Chromium Projects, “Chromium.” Chromium. https://www. chromium.org/home/, 2024

    work page 2024

  19. [19]

    Firefox Preload List

    Mozilla, “Firefox Preload List.” https://searchfox.org/mozilla-central/ source/security/manager/ssl/nsSTSPreloadList.inc, 2024

    work page 2024

  20. [20]

    A Longitudinal, End-to-End View of the DNSSEC Ecosystem,

    T. Chung, R. van Rijswijk-Deij, B. Chandrasekaran, D. Choffnes, D. Levin, B. M. Maggs, A. Mislove, and C. Wilson, “A Longitudinal, End-to-End View of the DNSSEC Ecosystem,” inUSENIX Security, 2017

    work page 2017

  21. [21]

    DNSSEC Misconfigurations in Popular Domains,

    T. Dai, H. Shulman, and M. Waidner, “DNSSEC Misconfigurations in Popular Domains,” inCANS, 2016

    work page 2016

  22. [22]

    One key to sign them all considered vulnerable: Evaluation of DNSSEC in the internet,

    H. Shulman and M. Waidner, “One key to sign them all considered vulnerable: Evaluation of DNSSEC in the internet,” inUSENIX NSDI, 2017

    work page 2017

  23. [23]

    HTTPS Everywhere

    Electronic Frontier Foundation (EFF), “HTTPS Everywhere.” Electronic Frontier Foundation. https://www.eff.org/https-everywhere, 2010

    work page 2010

  24. [24]

    CoStricTor: Col- laborative HTTP Strict Transport Security in Tor Browser,

    K. Davitt, D. Ristea, D. Russell, and S. Murdoch, “CoStricTor: Col- laborative HTTP Strict Transport Security in Tor Browser,” inPETS, 2024

    work page 2024

  25. [25]

    Server Location Verification (SLV) and Server Location Pinning: Augmenting TLS Authentication,

    A. Abdou and P. C. V . Oorschot, “Server Location Verification (SLV) and Server Location Pinning: Augmenting TLS Authentication,”ACM TOPS, vol. 21, no. 1, 2017

    work page 2017

  26. [26]

    Auto- matic Certificate Management Environment (ACME)

    R. Barnes, J. Hoffman-Andrews, D. McCarney, and J. Kasten, “Auto- matic Certificate Management Environment (ACME).” RFC 8555, 2019

    work page 2019

  27. [27]

    ARPKI: Attack Resilient Public-Key Infrastructure,

    D. Basin, C. Cremers, T. H.-J. Kim, A. Perrig, R. Sasse, and P. Szala- chowski, “ARPKI: Attack Resilient Public-Key Infrastructure,” inACM CCS, 2014

    work page 2014

  28. [28]

    Public Key Pinning Extension for HTTP

    C. Evans, C. Palmer, and R. Sleevi, “Public Key Pinning Extension for HTTP.” RFC 7469, 2015

    work page 2015

  29. [29]

    DNS Certi- fication Authority Authorization (CAA) Resource Record

    P. Hallam-Baker, R. Stradling, and J. Hoffman-Andrews, “DNS Certi- fication Authority Authorization (CAA) Resource Record.” RFC 8659, 2019

    work page 2019

  30. [30]

    Accountable Key Infrastructure (AKI): A Proposal for a Public-Key Validation Infrastructure,

    T. H.-J. Kim, L.-S. Huang, A. Perrig, C. Jackson, and V . Gligor, “Accountable Key Infrastructure (AKI): A Proposal for a Public-Key Validation Infrastructure,” inACM WWW, 2013

    work page 2013

  31. [31]

    Cer- tificate Transparency Version 2.0

    B. Laurie, A. Langley, E. Kasper, E. Messeri, and R. Stradling, “Cer- tificate Transparency Version 2.0.” RFC 9162, 2021

    work page 2021

  32. [32]

    A Security Model for Web-Based Communication,

    P. F. Tehrani, E. Osterweil, T. C. Schmidt, and M. W ¨ahlisch, “A Security Model for Web-Based Communication,”Communications of the ACM, vol. 67, no. 10, 2024

    work page 2024

  33. [33]

    Saner: Composing Static and Dynamic Analysis to Validate Sanitization in Web Applications,

    D. Balzarotti, M. Cova, V . Felmetsger, N. Jovanovic, E. Kirda, C. Kruegel, and G. Vigna, “Saner: Composing Static and Dynamic Analysis to Validate Sanitization in Web Applications,” inIEEE S&P, 2008

    work page 2008

  34. [34]

    The Web Origin Concept

    A. Barth, “The Web Origin Concept.” RFC 6454, 2011

    work page 2011

  35. [35]

    Content Security Policy Level 3

    M. West and A. Sartori, “Content Security Policy Level 3.” W3 Working Draft. https://www.w3.org/TR/CSP3/, 2024

    work page 2024

  36. [36]

    Noncespaces: Using Randomization to Enforce Information Flow Tracking and Thwart Cross-Site Scripting Attacks,

    M. V . Gundy and H. Chen, “Noncespaces: Using Randomization to Enforce Information Flow Tracking and Thwart Cross-Site Scripting Attacks,” inNDSS, 2009

    work page 2009

  37. [37]

    Coverage and Secure Use Analysis of Content Security Policies via Clustering,

    M. Ren and C. Yue, “Coverage and Secure Use Analysis of Content Security Policies via Clustering,” inIEEE EuroS&P, 2023

    work page 2023

  38. [38]

    Tor: The Second- Generation Onion Router,

    R. Dingledine, N. Mathewson, and P. Syverson, “Tor: The Second- Generation Onion Router,” inUSENIX Security, 2004

    work page 2004

  39. [39]

    Garlic Routing

    The I2P Project, “Garlic Routing.” I2P. https://geti2p.net/en/docs/how/ garlic-routing, 2024

    work page 2024

  40. [40]

    Lightweb: Private Web Browsing Without All the Baggage,

    E. Dauterman and H. Corrigan-Gibbs, “Lightweb: Private Web Browsing Without All the Baggage,” inACM HotNets, 2023

    work page 2023

  41. [41]

    The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA

    P. E. Hoffman and J. Schlyter, “The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA.” RFC 6698, 2012

    work page 2012

  42. [42]

    SMTP MTA Strict Transport Security (MTA-STS)

    D. Margolis, M. Risher, B. Ramakrishan, A. Brotman, and J. Jones, “SMTP MTA Strict Transport Security (MTA-STS).” RFC 8461, 2018

    work page 2018

  43. [43]

    Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints

    W. Griffin and J. Schlyter, “Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints.” RFC 4255, 2006

    work page 2006

  44. [44]

    Multi-Perspective Validation Improves Domain Validation Security

    J. Aas, D. McCarney, and R. Shoemaker, “Multi-Perspective Validation Improves Domain Validation Security.” Let’s Encrypt. https://letsencrypt. org/2020/02/19/multi-perspective-validation.html, 2020

    work page 2020

  45. [45]

    Multicast DNS

    S. Cheshire and M. Krochmal, “Multicast DNS.” RFC 6762, 2013

    work page 2013

  46. [46]

    IANA-managed Re- served Domains

    Internet Assigned Numbers Authority (IANA), “IANA-managed Re- served Domains.” Internet Assigned Numbers Authority. https://www. iana.org/domains/reserved, 2021

    work page 2021

  47. [47]

    The State of HTTPS Adoption on the Web,

    C. Kerschbaumer, F. Braun, S. Friedberger, and M. J ¨urgens, “The State of HTTPS Adoption on the Web,” inMADWeb, 2025

    work page 2025

  48. [48]

    HSTS-Enforced Artifacts

    A. van Diepen, A. Zapletal, and F. Kuipers, “HSTS-Enforced Artifacts.” https://artifacts.aaronvdiepen.nl/HSTS-Enforced, 2026

    work page 2026

  49. [49]

    A Method for the Construction of Minimum- Redundancy Codes,

    D. A. Huffman, “A Method for the Construction of Minimum- Redundancy Codes,” inInstitute of Radio Engineers, 1952

    work page 1952

  50. [50]

    Trie Memory,

    E. Fredkin, “Trie Memory,”Communications of the ACM, vol. 3, no. 9, 1960

    work page 1960

  51. [51]

    PowerDNS

    PowerDNS Team, “PowerDNS.” PowerDNS. https://www.powerdns. com/, 2024

    work page 2024

  52. [52]

    https://www.isc.org/bind/, 2024

    Internet Systems Consortium (ICS), “BIND.” Internet Systems Consor- tium. https://www.isc.org/bind/, 2024

    work page 2024

  53. [53]

    Unbound

    NLnet Labs, “Unbound.” NLnet Labs. https://unbound.docs.nlnetlabs.nl/ en/latest/, 2024

    work page 2024

  54. [54]

    Network Time Protocol Version 4: Protocol and Algorithms Specification

    J. Martin, J. Burbank, W. Kasch, and P. D. L. Mills, “Network Time Protocol Version 4: Protocol and Algorithms Specification.” RFC 5905, 2010

    work page 2010

  55. [55]

    List of Accredited Registrars

    Internet Corporation for Assigned Names and Numbers (ICANN), “List of Accredited Registrars.” https://www.icann.org/en/ accredited-registrars?view-all=true, 2024

    work page 2024

  56. [56]

    Root Zone File

    Internet Assigned Numbers Authority (IANA), “Root Zone File.” Inter- NIC. https://www.internic.net/domain/root.zone, 2024

    work page 2024