Also, what does "HSTS sites" mean. Does it mean (a) "official" HSTS via HTTP header alone, (b) "unofficial" HSTS via preload list (see RFC 6797 section 12.3), i.e., the list maintained by Google, hardcoded into a browser, or (c) both. The "unofficial" approach only seems feasible for a limited number of domainnames and unworkable for every domainname in existence.
In tests I have done on Chrome (YMMV), executing "Clear site data" via Developer Tools, or including
Clear-Site-Data: *
in an HTTP response header, e.g., added via a user-deployed proxy, will clear an "official" HSTS block, allowing the "MITM" to proceed.
Besides being generally annoying, HSTS allows for setting "supercookies" that persist even in "Incognito" mode
The RFC for HSTS even admits how it can be used for web tracking. Not too concerning for the advertising company sponsoring the RFC.
14.9. Creative Manipulation of HSTS Policy Store
Since an HSTS Host may select its own host name and subdomains thereof, and this information is cached in the HSTS Policy store of conforming UAs, it is possible for those who control one or more HSTS Hosts to encode information into domain names they control and cause such UAs to cache this information as a matter of course in the process of noting the HSTS Host. This information can be retrieved by other hosts through cleverly constructed and loaded web resources, causing the UA to send queries to (variations of) the encoded domain names. Such queries can reveal whether the UA had previously visited the original HSTS Host (and subdomains).
I use a loopback-bound forward proxy to enforce zero tolerance for HTTP across all programs, not just the web browser. Everything is sent via HTTPS. The proxy is configured to to check certificates, and deny connections, according to rules I set. I use a text-only browser for noncommercial, recreational web use so I need a forward proxy, if for nothing other than to deal with the spread of TLS. But I also use it for a whole laundry list of tasks.
Maybe it is just me, but HSTS, like much of Google's rhetoric, comes across as unfriendly if not hostile to proxies, regardless of who is running them. Consider this line from the RFC
"The rationale behind this is that if there is a "man in the middle" (MITM) -- whether a legitimately deployed proxy or an illegitimate entity -- it could cause various mischief (see also Appendix A ("Design Decision Notes") item 3, as well as Section 14.6 ("Bootstrap MITM Vulnerability"));"
"Mischief." Does that include inspecting one's own HTTP traffic on one's own network. How about blocking certain methods of tracking, data collection and advertising. Apparently it includes disabling HSTS.
Let's be honest. Google is an undisputed king of "mischief". The stakes for Google mischief are much higher and there have been too many fines to count. Consider the latest. How many people deploying their own proxies get fined $4B. (Arguably, an issue of "control" was at the heart of that decision.)
If the proxy is "legitimately deployed" then why not stay out of the network operator's way. Let them have control. Give the option to cede control to Google instead of making it a default.
I use HSTS for commercial, nonrecreational web use, when I have to use a "modern" browser. That is a small fraction of total web use for me.
Isn't it possible for the user to disable HSTS. A simple web search produces detailed instructions, from a CA.
https://sectigostore.com/blog/how-to-disable-hsts-in-chrome-...
Also, what does "HSTS sites" mean. Does it mean (a) "official" HSTS via HTTP header alone, (b) "unofficial" HSTS via preload list (see RFC 6797 section 12.3), i.e., the list maintained by Google, hardcoded into a browser, or (c) both. The "unofficial" approach only seems feasible for a limited number of domainnames and unworkable for every domainname in existence.
In tests I have done on Chrome (YMMV), executing "Clear site data" via Developer Tools, or including
in an HTTP response header, e.g., added via a user-deployed proxy, will clear an "official" HSTS block, allowing the "MITM" to proceed.Besides being generally annoying, HSTS allows for setting "supercookies" that persist even in "Incognito" mode
https://nakedsecurity.sophos.com/2015/02/02/anatomy-of-a-bro...
The RFC for HSTS even admits how it can be used for web tracking. Not too concerning for the advertising company sponsoring the RFC.
14.9. Creative Manipulation of HSTS Policy Store
Since an HSTS Host may select its own host name and subdomains thereof, and this information is cached in the HSTS Policy store of conforming UAs, it is possible for those who control one or more HSTS Hosts to encode information into domain names they control and cause such UAs to cache this information as a matter of course in the process of noting the HSTS Host. This information can be retrieved by other hosts through cleverly constructed and loaded web resources, causing the UA to send queries to (variations of) the encoded domain names. Such queries can reveal whether the UA had previously visited the original HSTS Host (and subdomains).
I use a loopback-bound forward proxy to enforce zero tolerance for HTTP across all programs, not just the web browser. Everything is sent via HTTPS. The proxy is configured to to check certificates, and deny connections, according to rules I set. I use a text-only browser for noncommercial, recreational web use so I need a forward proxy, if for nothing other than to deal with the spread of TLS. But I also use it for a whole laundry list of tasks.
Maybe it is just me, but HSTS, like much of Google's rhetoric, comes across as unfriendly if not hostile to proxies, regardless of who is running them. Consider this line from the RFC
"The rationale behind this is that if there is a "man in the middle" (MITM) -- whether a legitimately deployed proxy or an illegitimate entity -- it could cause various mischief (see also Appendix A ("Design Decision Notes") item 3, as well as Section 14.6 ("Bootstrap MITM Vulnerability"));"
"Mischief." Does that include inspecting one's own HTTP traffic on one's own network. How about blocking certain methods of tracking, data collection and advertising. Apparently it includes disabling HSTS.
Let's be honest. Google is an undisputed king of "mischief". The stakes for Google mischief are much higher and there have been too many fines to count. Consider the latest. How many people deploying their own proxies get fined $4B. (Arguably, an issue of "control" was at the heart of that decision.)
https://www.theregister.com/2022/09/14/european_court_fines_...
If the proxy is "legitimately deployed" then why not stay out of the network operator's way. Let them have control. Give the option to cede control to Google instead of making it a default.
I use HSTS for commercial, nonrecreational web use, when I have to use a "modern" browser. That is a small fraction of total web use for me.