Allow firefox to bypass HSTS errors

[KERR]

Using this test website, Firefox offers no way to proceed past the HSTS error:

https://subdomain.preloaded-hsts.badssl.com/

Vivaldi allows you to continue by clicking a proceed:

Chrome and Edge allow you to proceed by typing "thisisunsafe"

It would be handy to let us bypass these warnings (at our own risk), similar to how we can add exceptions to sites with invalid certs. It's not a common use case, but coming across one of these means my only option is to use Chrome/Edge/Vivaldi.

[BNF0]

@mtrantalainen

As @ocdtrekkie has argued, the "No User Recourse" portion of the HSTS RFC is malicious, and should be disregarded. A browser should be a "user agent", working on behalf of the user. However, with the current Firefox implementation, control over a website is being removed from the user.

Another issue is that it is possible to bypass a HSTS error by purging the HSTS list and disable HSTS preloading in about:config. But that disables HSTS for all pages. It's like disabling your antivirus system-wide to be able to store a single file wrongly flagged as malicious. But people are doing this, and so this RFC is actually making people less safe.

I agree that it shouldn't be as easy as a few clicks to skip a HSTS error. I even think that the implementation of other browsers ("thisisunsafe") is too lax. But there should be a way for power-users to skip a HSTS warning without needing to recompile the browser. Maybe allowing URLs in a string in about:config could do, but I'd prefer something even more "hacky" like pasting a command in the Console in Inspect Elements (where there is ample warning not to paste anything, and where an inexperienced user pasting unknown code could already do enough harm).

So, TLDR, I should be able to control my browser, instead of the browser controlling me. RFC 6797 is actively working against that, and thus should be partially disregarded.

[BNF0]

I've just realized that the whole of section 12 in RFC 6797 is non-normative. Even the title of section 12 says "User Agent Implementation Advice". Which means that the "No User Recourse" portion doesn't even need to be followed, while still being compliant with RFC 6797.

https://datatracker.ietf.org/doc/html/rfc6797#section-12

This invalidates the argument that a correct implementation of HSTS must not allow any user recourse

[TobiasSchn]

Different Page:

Refering to Quote:
"Firefox is simply following the standard which expliclitly says that the user shall not have an option to skip the security"

FireFox should stop patronising advanced users who need to turn this off, it's on their behalf if they want to do this, and not on team mozilla.

You are following best practice already by having unsafe proceeding blocked per default, this protects in all regular use cases without the user can do anything wrong. For users who intentionally want to turn this off (for whatever reason- not relevant at this point), then this browser (FireFox) is currently standing in the way.

[mtrantalainen]

If you don't agree with the standard, create a campaign to modify the standard. Mozilla Firefox has demonstrated time after time that they will modify their software to match the latest versions of standards.

Or if it's your broken server, simply fix the server because it will be much easier than modifying the standard.

[Maiyannah]

It's neither in many cases and that is precisely the problem with following the letter of the standard rather than examining it's intent and the goal it is trying to accomplish.

For instance, Firefox erroneously uses the user's system clock to consider certificate expiry time rather than the server's, and therefore unless you are in the same time zone as the server, or behind it, you will have a period of time before auto-renewals from Certbot, cPanel AutoSSL, or similar certificate automation go through, during which HSTS will refuse to allow a portion of the site's audience to receive the content.  This can be ameliorated through the use of a CDN, but at that point, you are basically talking about a site that this isn't a concern for anyways, because they're using paid certificates or otherwise presenting a paid CDN service's certificates.  This essentially pressures smaller website providers out of the question, which while Firefox may not care about them, I am certain the authors and maintainers of those websites certainly do.  I can certainly say for myself that I do.

An additional concern comes out of how this UX is designed in a way whereas HSTS denies access to the website for any certificate error - rather than the threat models expressed in the RFC 6797, which creates collateral concerns it does not address, and in a couple cases outright refuses to address.  From a network integrity point of view, this is unacceptable from the RFC.  From the UX experience on Firefox's side, this is non-compliant with the RFC - since it creates an overly broad scope of application that does not adhere to the specifications granted boundaries.

An example of this security failure is presented when there is a self-signed certificate which appears to be close to but not overlaping a TLD already in the system.  For example, the XBox Developer Console error referenced prior in this machine comes from the fact that the developer box uses a self-signed certificate and then connects to itself - which is, in itself, an abherration of the fact that browsers consistently refuse to allow a user to trust localhost in spite of these errors.  One can import the certificate, but many users of devices that do this, including wifi-enabled consumer-level printers, and consumer-level routers, do not have the technical expertise to navigate in a safe manner.

It has been proven time and time again that Firefox does not care for the security flaws of its products, such as the fact that it has a privileged execution remote backdoor built in, called Normandy.  (https://mozilla.github.io/normandy/)  I do not "trust" anyone with the keys to my browser from the internet, and nor should you, dear reader.

This is, at best, security theatre, and at worse, a blantant disrespect of the end user.  I very much have the personal perception fronts like this are used to shore up a false appearance of security when such remote execution vulnerabilities exist and continue to persist despite user complaints.

No, I reject the argument that this is "just the webserver's problem" categorically - this is a poor implementation of a misguided standard that Mozilla wishes to keep because it gives them the varnish of a secure product.  Perhaps some day, the FSF will support a better browser than this one, should someone ever make one.

[TobiasSchn]

Thanks for the hint, but i rather choose to not create an own campaign and make use of mozillas legitimate feedback channels, to underline the need for an exception, which does not modify the default,therefore keeping the standard intact anyways.

So my Feedback still stands- there are numerous people who are asking here since longer to implement an developer switch in about:config, and we would highly appreciate if this gets picked up.

Thank you.

[BNF0]

@mtrantalainenYou didn't read my message, did ya? The chapter you referenced previously (chapter 12) is non-normative. Even the title of section 12 says "User Agent Implementation Advice". Which means Firefox can implement a hidden workaround and still be compliant.

Receipts (links) are in my previous message