1528738 - (hsts-bypass) RFE: ability to bypass HSTS errors for power-users (about RFC section 12.1, No User Recourse)

Status: NEW

(Core :: Security: PSM, enhancement, P5)

Description

[Keith]

So I can't really find anything even in about:config to allow these type of errors to be bypassed. I know the RFC states the user is not supposed to have recourse, I have read the RFC (section 12.1, No User Recourse), and numerous other RFCs before. It seems kinda crazy to be forced find what needs to be changed recompile the browser.

I can understand not making this default behavior, but for someone who understands what they are doing why does it need to be so hard? Like I understand the team is probably worried about normal users and the fact the some may blindly apply about:config settings.

However, I don't even see an option in the developer edition of firefox. There has to be a better method of handling this than not trusting even technically competent users to adjust such things.

I will iterate again it's pretty frustrating to either recompile the browser or use a different browser for something that should be a pretty simple thing.

Comment 1

[Keith]

I will add the RFC mainly is concerned with in it's exact words "clicking through warning/error dialogs" with the as it states "fool" users into making the wrong decision and compromising themselves.

The standard states that: "This means that the user should not be presented with a dialog giving her the option to proceed."

I would conclude that a setting in about:config or any other place more fitting does not count as a recourse per the standard. A setting in about:config is not presenting anyone with an option to proceed.

Comment 2

[Dana Keeler (she/her) (use needinfo) [:keeler]]

What is it that you are trying to do that you need this as a solution?

Comment 3

[Keith]

Like depending on the issue it's can be as simple as disable preloading and clear the specific site settings via SiteSecurityServiceState.txt. It's just quite troublesome that if your working on something and if you don't have immediate access to change the server's mis-configuration.

It's just that there is not a direct setting to still allow loading HSTS site in case of error. So a lot time it's quicker to load an other browser when that happens.

Like even in the event of an revoked certificate I can just uncheck "Query OCSP servers", and load the page content. Despite the potential for a comprised cert. (far more risky if you ask me) Then go back and make sure check that to ensure any another certs are valid.

It's just a suggestion that there should be some way to continue without manually editing a file and restarting the browser or modify the browser and recompile to get such an option. It's pretty generic overall so I am not sure how what I am specifically doing applies.

Comment 4

[David Usher]

This is a very annoying and counterproductive "feature" that should be disabled. I am running into all kinds of sites that get errors. In this case FF will not let me download the Aleza app from the Microsoft website.

https://www.microsoft.com/en-us/p/alexa/9n12z3cctcnz?activetab=pivot:overviewtab

This bug has been messing people up for two months. Is anybody home at Firefox?

I have switched to Chrome. FF is useless with all the fake webpage errors it is throwing out.

Comment 5

[Dana Keeler (she/her) (use needinfo) [:keeler]]

You shouldn't be getting certificate errors on sites like microsoft.com. Usually this means antivirus software is intercepting your TLS connections. Try setting the preference "security.enterprise_roots.enabled" to true in about:config.

Also, please review our etiquette guidelines: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Comment 6

[David Usher]

about:config setting "security.enterprise_roots.enabled" fixed the problem.

I suggest the problem is in firefox. This is not affecting Chrome. If my malwarebytes was causing the problem I would expect it to impact all browsers.

Sorry but questioning why a two-month-old showstopper bug has not been fixed yet is not an etiquette issue.

The only TLS I can think of that should be blocked would be in a corporate setting where employees are installing remote access software such as LogMeIn. It is a huge security violation to have secure VPN connections running 7x24x365 between company PCs and potentially-unsecure non-company cloud servers. I don't see a way for browser code to trap that. Corporate Security would have to block connections from specific servers out there that provide remote access services. I know about this because I discovered and shut that down at at&t when I worked there.

Anyway, until the bug is fixed, it appears the temporary fix is for users to disable the feature by setting about:config "security.enterprise_roots.enabled" to true and hope that the user's antivirus is worth its salt. Malwarebytes does block infected websites so I am probably OK.

Comment 7

[Keith]

When I created this ticket it was more about the fact there was no advance option for instance about:config for developers ect... RFC (section 12.1, No User Recourse) clearly states there is not supposed be a dialog spam that someone could just click through for this error.

However, it sounds more visiting something that was not in firefox's trusted CA's, but was in the local certificate store for your OS.

Comment 8

[Keith]

Oh I should have been a little specific that RFC is 6797.

Comment 10

[ocdtrekkie]

The "No User Recourse" portion of the HSTS spec is malicious behavior, and should be disregarded as harmful. As it turns out, we currently have a recourse: we can bypass the error by using Microsoft Edge. We don't like recommending Edge, but when Firefox is not acting as a user agent, we are forced to.

I've spoken to one of the authors of the HSTS spec at length about this issue, and I strongly believe Firefox should prioritize at minimum a setting we can push via policy to allow HSTS to be bypassed or fully disabled. security.mixed_content.use_hstsc does not seem to provide any assistance in this regard.

Comment 11

[ocdtrekkie]

Note that this should be an S2 bug, there is no workaround within Firefox. If a server is sending the HSTS header, no amount of tampering with the cached HSTS data will allow you to bypass HSTS.

Comment 13

[Daniel Veditz [:dveditz]]

Apparently chromium browsers let you type 'thisisunsafe' on the error page and it magically bypasses the error, though the site does show the "Not Secure" badging as Chrome does with other exceptions such as for expired certs. This workaround appears to be widely known in some circles (https://www.google.com/search?q=thisisunsafe) but it's a pretty horrible incantation / easter-egg. If we were to do something to address this RFE it would be better to have a straightforward hidden pref that disables the lockout and gives you the override button (if the error is one of the overridable ones).

Slightly off-topic: the wording on chromium's security dropdown on a site with an exception is
You have chosen to turn off security warnings for this site. [Turn on warnings]
Do they really turn off all warnings for that site as implied by that wording? Could you click through on a site with an expired cert (common!) and now forevermore that site could be silently MITM'd and you'd never get warned again? I really hope it's just poor wording and they've tied the exception to the cert as we do, or at least to the same type of error.

bug 1414752 mentioned HSTS override among other things, but it's more useful to keep this request separate from a bug that was primarily focused on re-enabling old ciphers and protocols. In fact, I'd keep this and wontfix bug 1414752.

Comment 15

[Jon S]

See related thread on Connect: https://connect.mozilla.org/t5/ideas/allow-firefox-to-bypass-hsts-errors/idi-p/163

Comment 16

[Daniel Veditz [:dveditz]]

it's pretty frustrating to either recompile the browser or use a different browser for something that should be a pretty simple thing.

I'd support a power-user pref that allowed some way to override the error (the existing browser.xul.error_pages.expert_bad_cert could work, or an hsts-specific one) but there are workarounds that don't require recompiling. Depending on whether the state is due to the preload list or an HSTS header I give a couple of options in https://connect.mozilla.org/t5/ideas/allow-firefox-to-bypass-hsts-errors/idi-p/163#M15411

Comment 17

[Simmo Saan]

Since SiteSecurityServiceState.txt has been replaced with a proprietary binary file, I've found the safest (!) way to do this to be hex editing that binary file. I've spelled out the steps here for anyone that needs it: https://sim642.eu/blog/2024/08/10/firefox-hsts-bypass/.

Suggesting users to "Forget this site" or delete SiteSecurityServiceState.bin is a choice between their data (worse) and their security (worst).