Really? Most people? I cannot think of anyone from my family who would even think about it for a second - they would just get annoyed they can't get to their bank website or whatever and just click continue. Also what tech support? Me?

But now there is no button "continue", you have to click multiple buttons, which are not clearly labelled, in order to see the page. I'm sure 90% of people would not even be aware that you are able to continue.

Even more, for self-signed certificate on chrome, there is no button to continue for example. Check https://self-signed.badssl.com/

In your example, all I had to do was click advanced then proceed(Chrome on Android)

Ok, on chrome desktop there is no way to bypass the security

Yes, there is. I often have to use it to deal with some internal misconfigured site inside the corporate intranet (the cause is almost always that a certificate has expired, when it isn't it's because a host can be reached with two names and the cert matches only one of them, but that case can be fixed by using the proper URL). I have no trouble telling chrome desktop to bypass.

... and I always read the details before proceeding (finding out what chrome's problem with the cert is).

For some type of errors it is possible, for some other it isn't. Check the badssl website and test the various type of bad certs, you'll see.

From my experience working as on-campus tech support in college, most people who aren't tech savvy will quickly give up or look to someone else for help. They will likely not think to click Advanced -> Continue Anyway (unless they have been taught to do that before).

Tech support comes in many forms. The owner of the website, a friend who knows about computers, someone else in the workplace, the vendor they purchased their laptop from.

HSTS cannot be overridden. Which bank domain names are you thinking of that are not one of the twelve thousand names on the HSTS preload list? https://source.chromium.org/chromium/chromium/src/+/main:net...

I tried 5 banks (swedish and italian). None of them are in the list. I feel safer now :D :D :D

handelsbanken.se danskebank.se unicredit.it fideuram.it sella.it

Banks often have awful security systems. Kiwibank in NZ has a "two-factor security" system. All it is is a security questions thing where you click on screen to fill in 3 letters of the hidden answer. The on-screen keyboard makes it secure, you see? Against keyloggers.

I once wrote them a long email about what two-factor is actually supposed to be and why it exists, and got a reply basically saying "lol ok, our security is great ok?"

I've since switched away from them for a bank which does 'two-factor' by sending codes via SMS, but only when its algorithm decides that it needs to. That's not very often.

handelsbanken.se is on line 163144. (I was a little bit off on the length of the list before)

unicredit.it is not on the list, but unicredit.ba and unicredit.ro are. (Lines 7331 and 7332) It does send HSTS headers.

danskebank.se and sella.it are not in the file, nor are the base strings, but both sites do send HSTS headers.

fideuram.it is not on the list, and does not send HSTS headers, so they don't seem particularly interested in security. They also haven't set an A record for the root domain, so visiting `fideuram.it` returns NXDOMAIN. Only `www.fideuram.it` exists.

So this shows that your statement about the security of hsts headers was overblown?

You got me. I wildly overestimated the competence of Eurobanks. I'll never make the mistake of assuming an institution knows what it's doing again.

fideuram removed the phisical tokens for 2fa and moved to SMS, saying that it was because of some european directive… I went to read the directive. It basically said to not use sms and avoid apps in favour of dedicated 2fa devices for banking.

Hsts solves sslstrip, I do not believe it enforces cert pinning. Iirc browsers deprecated cert pinning some time ago.

I've seen HSTS not let me continue without the server having the expected certificate recently, so I think that's still a thing.

That might be because of certificate transparency rather than certificate pinning.

"Aside from that, this isn't possible for HSTS sites."

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

   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

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.

Thanks for the informative post.