How to fix missing "I Understand the Risks" section / "Add Exception..." button, Roman number 2

[tlaloc77]

I just encountered a site I have been using for months and until a few hours ago (which means that I have number of tabs open to that site) and their certificate expired less than an hour ago (at the time I was reloading some tab): https://yt.cdaut.de/

Now what.

This is a case where
- I know that the site is safe, it was considered to be officially safe until about an hour ago, and
- I won't login or provide any personal data other than my IP address anyway.

Yes, they forgot their certificate would expire today and they need to fix that ASAP but until they get that done? The site is plain inaccessible and there seems no way around that. Or is there?

(I searched and "How to fix missing "I Understand the Risks" section / "Add Exception..." button" seems to fit exactly what would be needed but the thread is closed so I had to create a new one.)

[Pentium4User]

There is the section "I understand this risk". There you can create a temporary or permanent exception.
Works for me.

[tlaloc77]

There is the section "I understand this risk". There you can create a temporary or permanent exception.
Works for me.

Sorry for the stupid question: Where can I find this section? Edit: I'm using Pale Moon 32.5.1 (64 bit) on antiX Linux. Do you use a different one?

This is what I see when reloading one of said tabs:

[Pentium4User]

For me it looks different, but I don't know where to enable the mode where you can create an exception.

[tlaloc77]

Suspected as much. This worked for earlier versions of Pale Moon, maybe it still works on another operating system (not only Windows). Thank you anyway

By the way, setting browser.xul.error_pages.expert_bad_cert = true (as suggested to NOT do in the original thread) didn't work.

But it's already fixed, looks like they updated the certificate.

Therefore: "Sorry for the noise. (Amber Broos)"

[Moonchild]

It depends on exactly what the error is. Some errors do not let you override it with an exception, depending on the class of error and on the way the website is configured (especially if you have previously visited it). This seems to be a simple expired cert so it should give you the option to make an exception; the fact that it doesn't means there's something more serious wrong with the cert.
However, it seems that the webmaster has noticed and updated the cert (I had no issue connecting to it).

As an aside: Some errors may be bypassed by going into about:config and setting browser.xul.error_pages.expert_bad_cert to true, but that's not recommended unless you are, in fact, an expert and know how to exactly evaluate the issue with sites throwing security errors. Even that setting does not allow exceptions to all classes of errors though since some are plainly always bad and guaranteed to be malicious.

[tlaloc77]

Thank you - It's nice to get some special info, I may have learned something.

After looking around the config, rather lost, and during writing my 2nd comment/1st answer, I tried browser.xul.error_pages.expert_bad_cert, by typing "expert" into the filter of about:config, which gave me only two and only one of them was boolean, so I'm sure I didn't mis-type anything. But setting it to true did nothing. (Edit 2: Meanwhile I changed it back.) Which might support your idea about something else being wrong.

Near the end they had fixed the certificate (or got a new one) so I guess we'll never know. Unless YOU can figure out something from the screenshot of the error message - it doesn't tell me anything but the expiration problem.
If you tried connecting to https://yt.cdaut.de after my last answer before yours, you got no error anymore. And the site is still accessible, I just checked.

But I still have one tab that shows the error because I didn't reload it since then. It's the last remainder of the incident. Can that still be of any use?

Edit: Could my add-ons have contributed to the problem? I just made a screenshot of my active add-ons, wanna see? Nothing has changed between back then and now except: The whitelist of Suspender, and I unchecked to show the Suspender-icon in the address bar. I believe I added yt.cdaut.de to the whitelist of Suspender after the site was back to normal but I'm not 100% sure. But I am 100% sure that I changed nothing but that.

[Kris_88]

You should see "I Understand the Risks" here:
https://expired.badssl.com/

The host
https://yt.cdaut.de/feed/popular
uses the "strict-transport-security" response header, so this button is hidden.

https://repo.palemoon.org/MoonchildProd ... .xhtml#L88

[tlaloc77]

Can confirm that the button is there in the first case.

So that's it! Thank you very much!

[Kris_88]

BTW, here is the code that explains why the preference browser.xul.error_pages.expert_bad_cert does not work in this case:

https://repo.palemoon.org/MoonchildProd ... .cpp#L4984

// HSTS takes precedence over the expert bad cert pref. We
// never want to show the "Add Exception" button for these sites.

[Moonchild]

Yup all that is by design and the way it should be, which is why I said "especially if you have visited the site before" (HSTS is stored permanently* in the browser, by design) -- if they send an HSTS header they are making a solid commitment to have TLS set up and configured properly long-term. If they break with that promise then that's on them. No exceptions are allowed with that commitment.

* "permanently" means unless you clear it, of course. It's part of the "site connectivity data" in the "clear history" dialog (ctrl+shift+del)

[tlaloc77]

Got it. @Kris_88: Thanks for the link into the code!

But - can that happen (to me) again? Probably YES, even though I'm now more suspicious about HSTS. Because:

Yup all that is by design and the way it should be, which is why I said "especially if you have visited the site before"

You did but I didn't connect the dots from the missing option to them having used HSTS and that that is such a commitment. Now I know, but still:

(HSTS is stored permanently* in the browser, by design) -- if they send an HSTS header they are making a solid commitment to have TLS set up and configured properly long-term. If they break with that promise then that's on them. No exceptions are allowed with that commitment.

Well, I had not made this thread if I had known that and had known that the site had sent that HSTS header. When you mentioned that something else is most likely wrong with the certificate, did you already know or suspect that they had used an HSTS header in the past? I didn't.

So - how about putting another line into that error message, maybe something like e.g. "The site has sent an HSTS header in the past. Which is still stored stored permanently* in the browser, this is by design and disallows the option to accept an invalid certificate, no exception." or similar, for example. Thereby making clear that the button "Get me out of here" is the only option to offer. Followed by said button.

As it is now, there was/is no hint in the error message about HSTS. And even your remark about something wrong in addition to an expired certificate didn't put me on the right track (besides the fact that the problem was already solved by that time.)
Guys, you must be aware that probably about 99% of all *ogle Chrome users have no clue about such things. It's probably not as bad with Firefox and even (much) less bad with all the niche browsers including Pale Moon, since some advertise privacy advantages over *ogle Chrome and FF, but as I said, the error message about the expired certificate didn't make me suspicious about HSTS.
Is HSTS the only possible reason for the option to accept an invalid certificate not being available? If not, you must tell the user seeing the error message about the HSTS reason. If yes, you should still mention it, getting made aware of it would have saved time, mine and yours.

(I consider myself as a somewhat "advanced" user of browsers, I'm interested in such things but it's not my area of expertise, I'm still only a user, not a developer (of any kind regarding the internet). I had heard of HSTS but didn't know or remember the details, e.g. it being a privacy issue. Anyone below my level of "being interested in this matter" would have needed luck to come to the correct conclusion. A friend of mine is somewhat above me about this, I'll ask him about it later. Also, in hindsight it's a pity that I didn't try to access the site with any other browser than PM, just to see their error message.)

* "permanently" means unless you clear it, of course. It's part of the "site connectivity data" in the "clear history" dialog (ctrl+shift+del)

Now that I read the whole Wiki page about it while being fully awake, the "trust on first use" condition would have set me on the track to delete all its cookies and maybe I would have thought of deleting the site from my browsers history of visited sites by myself, maybe not (especially while being excited/confused about a missing detail in an error message). So having this mentioned in the error message would definitely be nice. Or putting in a link to this or the original thread in this forum.

[Moonchild]

It's neither our task to be educators at every turn in the browser, nor is it the task of end users to know all the ins and outs of every protocol. It is solely the task of the webmasters to ensure they understand what it means when they use certain stringent security measures on their domain.
We are doing exactly what we should. Not allowing you to add an exception to something that is a big red flag (because you did visit the site before and as an average user should not be allowed to bypass HSTS restrictions) is exactly what we should do. Not presenting a silver platter bypass for it is exactly what we should be doing because it is the exact scenario you would run into if there was a genuine domain hijack taking place.
If a webmaster enables HSTS it means the site's access will break (by design, in the standard) if their TLS becomes insecure in any way. Not "kinda break" or "break with bypass options". No, it will break.

[Kris_88]

We are doing exactly what we should.

However, it would be nice to add an explanation as to why it is not possible to create an exception. This is a good idea...

[Moonchild]

There are multiple reasons why an exception isn't allowed.
we'd have to then start adding conditionals and checks for every single situation just to tell users more details about why they can't connect. I'm really not into that, sorry.

[gepus]

But - can that happen (to me) again? Probably YES, even though I'm now more suspicious about HSTS.

No need to be suspicious about HSTS.
The settings are stored in "SiteSecurityServiceState.txt" which is located in your profile folder.
You can inspect or edit them. If you delete the file it will be restored during browser restart.

[tlaloc77]

Gosh, took me too long.

It's neither our task to be educators at every turn in the browser, nor is it the task of end users to know all the ins and outs of every protocol. It is solely the task of the webmasters to ensure they understand what it means when they use certain stringent security measures on their domain.

I suspect you got me wrong.
This error message is the equivalent of "it doesn't work for a specific reason and there's nothing you can do about it." while the browser knows why I can't do anything about it but doesn't tell me.

We are doing exactly what we should. Not allowing you to add an exception to something that is a big red flag (because you did visit the site before and as an average user should not be allowed to bypass HSTS restrictions) is exactly what we should do. Not presenting a silver platter bypass for it is exactly what we should be doing because it is the exact scenario you would run into if there was a genuine domain hijack taking place.

Then you get threads like this one. If you are satisfied with getting threads like this, once in a while, OK. That is your problem, then. You could also write an FAQ section about all this.

And let's be honest: I would not have bothered most of the big browser developers - Brave (Chromium-based) being the exception, they have (or had, some years ago) a very lively forum and might have helped me understand what's going on even faster than here, including help about getting it to work just one more time. But I prefer Mozilla-based browsers and if possible XUL based browser, of which, to the best of my knowledge, there are only 3 left: Pale Moon, Basilisk, and Legacy Waterfox. That said, under Linux I have some more to try.
I would have just just tried a different browser.

If a webmaster enables HSTS it means the site's access will break (by design, in the standard) if their TLS becomes insecure in any way. Not "kinda break" or "break with bypass options". No, it will break.

Understood. Having a bypass option was not my primary request anyway, I want(ed) an error message that tells me why I can't do anything about it.

I couldn't even tell them. But admittedly, for being able to tell them I'd need a bypass option which will break stuff in the general case, so you're probably right.

I understand you don't want to extend the error message with a further explanation. OK.
Then I guess all is said and done, problem solved and I even learned a couple of things, including that the user is not supposed to know certain things that causes the browser to behave in a certain way, just now.

Anyway - all this was quite helpful for me. I'm (more) aware of what's going on and the next time something like that happens I will just use another browser, as that's obviously the simplest way to do a quick check. (But that may ultimately lead to complaints that contain "... but it works in <other browser>!" - the lack of understanding the deeper details will lead to poorer complaints where the user doesn't know what to provide.)

---- merged ----

There are multiple reasons why an exception isn't allowed.
we'd have to then start adding conditionals and checks for every single situation just to tell users more details about why they can't connect. I'm really not into that, sorry.

You already have to add conditionals or have added them in the past so that the browser does the correct thing. You "only" have to add improvements to the error message. I understand that this means additional work. But wouldn't it then save time later on?

[tlaloc77]

But - can that happen (to me) again? Probably YES, even though I'm now more suspicious about HSTS.

No need to be suspicious about HSTS.
The settings are stored in "SiteSecurityServiceState.txt" which is located in your profile folder.
You can inspect or edit them. If you delete the file it will be restored during browser restart.

Thanks, good to know. I'm learning a lot here!
Alas, I also need to know (or suspect) that HSTS is involved in a certain error. Then again, maybe I should delete that file every day, that would probably take care of the privacy issue HSTS introduced.

Off-topic:
You may have heard of web sites that show you a certain price (e.g. for a certain journey) on the first visit and a higher price on your next visit (for the same journey). This was done previously by (normal) cookies but now having the HSTS "supercookies", (normal) cookies wouldn't be needed anymore. I have already noticed that the *ogle-captcha site recognizes me again when I come back several minutes later without using (normal) cookies.

[gepus]

Then again, maybe I should delete that file every day, that would probably take care of the privacy issue HSTS introduced.

To make it clear - I don't advise anybody to mess with default settings.
However, instead of deleting a file every day, wouldn't making it write protected (schreibgeschützt) be a less time consuming task?

[tlaloc77]

...
However, instead of deleting a file every day, wouldn't making it write protected (schreibgeschützt) be a less time consuming task?

Yes. But same as with cookies: Sometimes they may be useful. E.g. the captchas, not needing to solve them every 10 minutes is an advantage.