Open Bug 1528738 Opened 8 months ago Updated 6 months ago

Bypass HSTS errors (about RFC section 12.1, No User Recourse)

Categories

(Firefox :: Security, enhancement, P5)

enhancement

Tracking

()

UNCONFIRMED
Future

People

(Reporter: admin, Unassigned)

Details

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.

Priority: -- → P5

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.

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

Flags: needinfo?(admin)

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.

Flags: needinfo?(admin)

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.

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

Flags: needinfo?(drusher)

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.

Flags: needinfo?(drusher)

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.

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

You need to log in before you can comment on or make changes to this bug.