Chrome:The website uses HSTS. Network errors...this page will probably work later

Question

I am developing against localhost. This morning right after I used fiddler I started getting this error on chrome (works correctly in firefox)

"You cannot visit localhost right now because the website uses HSTS. Network errors and attacks are usually temporary, so this page will probably work later."

Now localhost works in chrome only if fiddler is running. I already made sure the proxy redirects that fiddler makes are corrected when fiddler shuts down.

I also tried importing the certificate to my trusted root and restarting the browser (and also the machine).

Answer 1

One very quick way around this is, when you're viewing the "Your connection is not private" screen:

type badidea

type thisisunsafe (credit to The Java Guy for finding the new passphrase)

That will allow the security exception when Chrome is otherwise not allowing the exception to be set via clickthrough, e.g. for this HSTS case.

This is only recommended for local connections and local-network virtual machines, obviously, but it has the advantage of working for VMs being used for development (e.g. on port-forwarded local connections) and not just direct localhost connections.

Note: the Chrome developers have changed this passphrase in the past, and may do so again. If badidea ceases to work, please leave a note here if you learn the new passphrase. I'll try to do the same.

Edit: as of 30 Jan 2018 this passphrase appears to no longer work.

If I can hunt down a new one I'll post it here. In the meantime I'm going to take the time to set up a self-signed certificate using the method outlined in this stackoverflow post:

How to create a self-signed certificate with openssl?

Edit: as of 1 Mar 2018 and Chrome Version 64.0.3282.186 this passphrase works again for HSTS-related blocks on .dev sites.

Edit: as of 9 Mar 2018 and Chrome Version 65.0.3325.146 the badidea passphrase no longer works.

Edit 2: the trouble with self-signed certificates seems to be that, with security standards tightening across the board these days, they cause their own errors to be thrown (nginx, for example, refuses to load an SSL/TLS cert that includes a self-signed cert in the chain of authority, by default).

The solution I'm going with now is to swap out the top-level domain on all my .app and .dev development sites with .test or .localhost. Chrome and Safari will no longer accept insecure connections to standard top-level domains (including .app).

The current list of standard top-level domains can be found in this Wikipedia article, including special-use domains:

Wikipedia: List of Internet Top Level Domains: Special Use Domains

These top-level domains seem to be exempt from the new https-only restrictions:

• .local
• .localhost
• .test
• (any custom/non-standard top-level domain)

See the answer and link from codinghands to the original question for more information:

answer from codinghands

Answer 2

When you visited https://localhost previously at some point it not only visited this over a secure channel (https rather than http), it also told your browser, using a special HTTP header: Strict-Transport-Security (often abbreviated to HSTS), that it should ONLY use https for all future visits.

This is a security feature web servers can use to prevent people being downgraded to http (either intentionally or by some evil party).

However if you then then turn off your https server, and just want to browse http you can't (by design - that's the point of this security feature).

HSTS also does prevents you from accepting and skipping past certificate errors.

To reset this, so HSTS is no longer set for localhost, type the following in your Chrome address bar:

chrome://net-internals/#hsts

Where you will be able to delete this setting for "localhost".

You might also want to find out what was setting this to avoid this problem in future!

Note that for other sites (e.g. www.google.com) these are "preloaded" into the Chrome code and so cannot be removed. When you query them at chrome://net-internals/#hsts you will see them listed as static HSTS entries.

And finally note that Google has started preloading HSTS for the entire .dev domain: https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/

Answer 3

Click anywhere in chrome window and type thisisunsafe (instead of badidea previously) in chrome.

This passphrase may change in future. This is the source

https://chromium.googlesource.com/chromium/src/+/master/components/security_interstitials/core/browser/resources/interstitial_large.js#19

According to that line, type window.atob('dGhpc2lzdW5zYWZl') to your browser console and it will give you the actual passphrase.

This time the passphrase is thisisunsafe.

Answer 4

I had this issue with sites running on XAMPP with private hostnames. Not so private, it turns out! They were all domain.dev, which Google has now registered as a private gTLD, and is forcing HSTS at the domain level. Changed every virtual host to .devel (eugh), restarted Apache and all is now well.

Answer 5

I recently had the same issue while trying to access domains using CloudFlare Origin CA.

The only way I found to workaround/avoid HSTS cert exception on Chrome (Windows build) was following the short instructions in https://support.opendns.com/entries/66657664.

The workaround:
Add to Chrome shortcut the flag --ignore-certificate-errors, then reopen it and surf to your website.

Reminder:
Use it only for development purposes.

Answer 6

I see there are so many useful answers here but still, I come across a handy and useful article out there. https://www.thesslstore.com/blog/clear-hsts-settings-chrome-firefox/

I ran into the same issue and that article helped me to what exactly it is and how to deal with that HTH :-)

Answer 7

Encountered similar error. resetting chrome://net-internals/#hsts did not work for me. The issue was that my vm's clock was skewed by days. resetting the time did work out to resolve this issue. https://support.google.com/chrome/answer/4454607?hl=en

Answer 8

I encounter same error, and incognito mode also has same issue. I resolve this issue by clear Chrome history.

Answer 9

I have been suffering of this issue for very long time. I was unable to open websites like GitHub. I almost tried all the answer on web and not anyone worked. Tried to reinstall chrome also. I found the solution for this from our network guy and it worked. There is a fix in registry which will resolve this error for permanent basis.

1. Press Windows+R key to open run dialogue box
2. type : regeditand press enter to open registry
3. In the tree view at left click through following path HKEY_LOCAL_MACHINE > SOFTWARE > POLICIES > Microsoft > SystemCertificate > Authroot
4. Now double click on DisableRootAutoUpdate on the right and set it to 0(zero) in the dialogue box appearing
5. Restart your PC to apply registry changes and you will not get this error anymore

The solution above is for Windows 8. It is almost identical in later versions but i’m not sure for earlier versions like XP and vista. So that needs to be checked.

Answer 10

This policy mechanism guarantees only secure HTTPS interactions with websites (and never HTTP). The HTTP Strict Transport Security acronym stands for HTTP Strict Transport Security. Keeping the protocol up-to-date prevents attacks on the security protocols like this one.

The vulnerability within HSTS that HSTS responds to was first discovered by a 2009 BlackHat Federal talk titled "New Tricks for Defeating SSL in Practice." Marlinspike's tool, SSLStrip, demonstrates the vulnerability in question.

A secure HTTPS connection is converted back to an unsecured HTTP connection using the tool. The solution is to use HSTS to communicate with the browser that HTTPS connections are always recommended. By using HSTS, cookies will no longer be intercepted by exploits such as Firesheep that steal login credentials through cookies.