Ugh that's the worst. I work on servers where the GUI can only be accessed using HTTPS, but its all internal so many clients don't bother. And I don't know why browsers sometimes don't let me say "continue anyway" but it's super frustrating.

Using HSTS on a website will generally prevent your browser from allowing you to continue, which is fair: the website owner has explicitly indicated the website should only ever be used over a encrypted connection, and that is not the case..

I understand who owns the website.

Who owns my browser?

To be RFC compliant, it MUST NOT allow the user to ignore the errors.

   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.

   Essentially, "any warnings or errors" means anything that would cause
   the UA implementation to announce to the user that something is not
   entirely correct with the connection establishment.

   Not doing this, i.e., allowing user recourse such as "clicking
   through warning/error dialogs", is a recipe for a man-in-the-middle
   attack.  If a web application issues an HSTS Policy, then it is
   implicitly opting into the "no user recourse" approach, whereby all
   certificate errors or warnings cause a connection termination, with
   no chance to "fool" users into making the wrong decision and
   compromising themselves.

https://tools.ietf.org/html/rfc6797#section-12.1

Well I suppose curl/wget will never be RFC compliant user agents (curl -k, wget --no-check-certificate).

But somehow I think they'll still be used...

wget writes a ~/.wget-hsts file with the HSTS information for any URI you have accessed that served an HSTS header.

Making it ignore --no-check-certificate if the file has an entry for the hostname you are visiting should be trivial, if it hasn't been done already.

Exactly.

You can configure most major browsers to forget HSTS entries they already know about, so to the question of who owns your browser wrt honoring HSTS, I'd say it's the user.

http://classically.me/blogs/how-clear-hsts-settings-major-br...

Though now I'm curious if Chrome can be configured to forget HSTS for Google sites.

I'm not 100% certain, but is that to just delete the HSTS Header that is saved into the browser?

The manufacturer.

try typing 'badidea' on that page and report back if it works. :)

Can you explain that trick?

I Googled it and found this:

https://www.reddit.com/r/sysadmin/comments/42xd4i/chrome_dan...

Well there's a nice little easter egg, I could have really done with that a week ago while doing a load of provision testing with LE staging certs!

I love how discoverable GUIs are.

Very nice :) Thanks.

actually works

I get the error on the NIST web site [0] as well. I do have the "Proceed to ..." option, though, as you can see in my screenshot [1].

The same thing happens on the Chase Bank URL [2] mentioned in the article. Clicking "Proceed to ..." then redirects me to another URL [3] which throws up the same error. If I click "Proceed to ..." on that URL, I then get an ironic login page [4].

  $ lsb_release -d
  Description:    Ubuntu 16.04.1 LTS

  $ apt show chromium-browser | grep ^Version
  Version: 53.0.2785.143-0ubuntu0.16.04.1.1254

  $ chromium-browser --version
  Chromium 53.0.2785.143 Built on Ubuntu , running on Ubuntu 16.04

Perhaps there's a setting somewhere that you've toggled? Maybe it's HSTS or something similar?

[0]: https://www.nist.gov/

[1]: http://i.imgur.com/QbgBxyB.png

[2]: https://choosemyreward.chase.com/

[3]: https://chaseonline.chase.com/Logon.aspx

[4]: http://i.imgur.com/KFqiwNG.png

I do get the "proceed to www.xxx (unsafe)" under Advanced. Version 53.0.2785.143 Built on Ubuntu , running on Ubuntu 16.04 (64-bit)

> In my experience that past couple days, I get the warning on about 10-25% of major web sites.

I'm finding about the same, including major sites like Mint.com and Amazon (or part of Amazon's CDN for images, anyway). I'm running a slightly older Ubuntu and as of now, Chromium 53 is the latest in the repos...