2

The HSTS standard states the following:

12.1. No User Recourse

Failing secure connection establishment on any warnings or errors (per Section 8.4 ("Errors in Secure Transport Establishment")) should be done with "no user recourse". This means that the user should not be presented with a dialog giving her the option to proceed. Rather, it should be treated similarly to a server error where there is nothing further the user can do with respect to interacting with the target web application, other than wait and retry.

https://www.rfc-editor.org/rfc/rfc6797#section-12.1

I can see why for non-HSTS hosts (such as networking devices) it would be beneficial to have a way to bypass the warning quickly, for setting up and deploying a valid certificate, as these devices may come out of the box with an invalid certificate.

Given that the HSTS standard says that there should be no user recourse, and that there is already a --ignore-certificate-errors flag which achieves the same aim, what is the justification for giving users an easier way to get around HSTS issues, rather than limiting the bypass to non-HSTS hosts?

Improve this question
4
  • 2
    Nice blog about this: scotthelme.co.uk/bypassing-hsts-or-hpkp-in-chrome-is-a-badidea -- Related question: stackoverflow.com/questions/35274659/…
    – StackzOfZtuff
    Oct 14, 2018 at 13:55
  • The idea is that they're obscure enough that an uninformed user won't do it accidentally. There are some scenarios where you might need to do it intentionally. E.g. some certificate has expired and you urgently need to use it.
    – paj28
    Nov 15, 2018 at 23:37
  • 1
    It says no recourse after an error. By definition an error is not a warning, an error is an impossibility. What is an error in accepting a certificate is by definition the function of the opinion of what a valid certificate is, which is, well, an opinion and thus by definition subjective. (Although an unparsable certificate would count as objectively invalid.)
    – curiousguy
    Dec 9, 2018 at 22:18
  • 1
    Denying that trust is subjective and that the acceptability of root certificates is an opinion is the root denial that led us to having a bunch of "authorities" few people know about and that produce regular controversies and scandals. The browser works for the user and must do what the user wants, by definition. It's his computer. The rest is a distraction.
    – curiousguy
    Dec 9, 2018 at 22:19

2 Answers 2

Reset to default
7

It's probably within the spec. The phrase is regularly changed, and it's not something you happen upon by chance. You have to know what you're looking for (e.g. google 'chrome hsts bypass'), which indicates that you're aware of the risk.

The bar for using this is a lot higher than clicking 'Proceed', as it is not documented in the Error Message shown to the user.

In addition, there's really no certifying authority when it comes to RFCs. Parts of them are open to interpretation, and there is no official body that will tell you if you comply with a RFC or not.

Having a way to bypass it for users that do understand the implications is in my opinion wise, as it makes it easier to dissect if your own site is under attack - or if you are simply investigating for instance a phishing attack against your organization.

In short - it's an balancing act between being impossible and really obscure. I think the thisisunsafe is an reasonable balance. Unlikely to be used by unknowledgeable users, yet available when needed.

Improve this answer
1
  • 4
    Honestly, I don't understand people even asking questions like this. Trying to force things on users is an act of arrogance and disrespect. Developers doing it would be dictators or even tyrants if they found themselves in a position of political power. There's a difference between protecting people from unconsidered actions and telling them what they have to do.
    – Bachsau
    Nov 24, 2019 at 15:53
4

Absolutely it is justified. The HSTS standard is strictly wrong, though its exact wording adds at least two caveats which clearly allow for various options, including such "hidden" features as a secret passphrase, or a command-line flag, or arguably even the ability to register a site/address/certificate/etc. as trusted. All it really disallows is the direct "proceed" button.

Of course one should only use any security bypass workaround if one knows exactly what one is doing.

I don't agree that the secret passphrase currently used by Chrome is ideal though; and I think the blanket --ignore-certificate-errors is a very large and unusable hammer. I believe the mechanism originally employed (at least on macOS and I think Windows) whereby a certificate could be registered as trusted (perhaps just for specified sites and/or users) was infinitely better, and the fact that Chrome silently ignores such settings now is abhorrent behaviour and a huge UX faux pas.

Indeed I think the only-slightly-hidden "proceed anyway" button should have remained for all such warning pages, though perhaps it should have asked for your password or some such other annoyance.

The most annoying part of the current UX in Chrome is the stupid useless suggestion that the user might "wait and try again".

Improve this answer
2
  • 3
    For the average user "wait and try again" is a valid and useful suggestion. If the site is still maintained the administrator should be fixing the certificate error before too long.
    – AndrolGenhald
    Nov 15, 2018 at 23:04
  • @AndrolGenhald For the average user, understanding what https does and does not guarantee is "valid and useful". Also, enabling the user to make security decisions is "valid and useful".
    – curiousguy
    Dec 8, 2018 at 17:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .