48

I have following setup:

The application https://app.domain.de is our production environment and is automatically forwarded to use HTTPS. All works fine here. On top, there are several development versions of the application for our QA-Team accessible via http://develop.app.domain.de (no HTTPS needed here).

The problem begins here: As soon as I visit https://app.domain.de Chrome (and I guess also other browsers) forward http://develop.app.domain.de (no HTTPS) also to https://develop.app.domain.de (HTTPS). I can of course disable HSTS and clear the cache for this domain and http://develop.app.domain.de will work, but only until I visit https://app.domain.de again.

I cannot enable HTTPS for our development environments as you need to have at least a Hobby Plan in Heroku to do so and that would therefore be a waste of money for all our development and test environments of the application. I would also like to keep the url schema.

So my questions is how can I disable this nasty forwarding (HSTS) permanently?

chillyistkult
  • 959
  • 2
  • 11
  • 22

3 Answers3

236

You can type thisisunsafe anywhere on the Google Chrome warning page and it will load it without warning. No joke.

Evan Carroll
  • 78,363
  • 46
  • 261
  • 468
stdclass
  • 2,932
  • 2
  • 19
  • 16
  • 4
    This will permanently whitelist the website. How do I undo this? – Franklin Yu Mar 12 '18 at 14:20
  • OMG uber helpful thanks. I have valid DNS and self-signed cert on WIFI but this is a dev laptop and I'm not always on a network at all - this helps greatly. Apparently "allow untrusted localhost certs" isn't enough with HSTS even if you're self-signed. – BoeroBoy Feb 12 '19 at 13:16
  • 2
    https://stackoverflow.com/questions/35274659/does-using-badidea-or-thisisunsafe-to-bypass-a-chrome-certificate-hsts-error/ – Barry Pollard Feb 13 '19 at 19:37
  • 11
    @FranklinYu click on the certificate (padlock) in the address bar and [click](https://stackoverflow.com/a/35275060/396967) "Re-enable warnings" – kynan Jun 27 '20 at 13:16
  • 1
    dude, you really made my day! always needed to navigate to edge to load a specific site. now it doesnt work anymore in edge, so i needed an alternative. absolutely life saver, thanks! – Chris Schrut Sep 29 '20 at 06:22
  • WHERE do you type this? Do you just click on the screen and type these letters? I tried and no effect – Daniel Williams Aug 05 '22 at 17:04
  • @DanielWilliams you just type the letters while the error page is visible. It's been some time since I had this issue, maybe it got removed – stdclass Aug 23 '22 at 07:49
  • I can confirm this still works on latest Chrome Dev – nickpapoutsis Jan 25 '23 at 01:12
  • @DanielWilliams try refreshing the page after typing in the letters. Still works for me on latest Chrome stable – nareddyt Jan 28 '23 at 18:46
  • Downvoted because this has nothing to do with HSTS. I have an https domain (*without* `includeSubdomains`!) with an http subdomain. Chrome redirects the subdomain to HTTPS, which breaks everything because the subdomain doesn’t even listen on :443. If I clear the HSTS cache the page loads correctly (no warning); otherwise I get a connection error because :443 doesn’t respond. There’s no warning page where I could enter this "cheat code" (terrible UX btw). – bfontaine May 04 '23 at 10:11
5

On the main domain, you can remove the includesubdomains option of your HSTS header, so it will not redirect the sub domain.

However, this is not the most secure solution. To be effective, it's better to set HSTS+includesubdomains on all your domains and subdomains (or an attacker car fake the domain "http://secure.yourdomain.com" for example).

So the most secure solution is to use a self-signed certificate (or a real one) for your dev domains and import it before in your browsers.

Tom
  • 4,666
  • 2
  • 29
  • 48
0

HSTS is not "nasty" - it's a security feature. And one that your domain has voluntarily chosen to activate!

You can remove includeSubDomains option from production so it's only applied to the top level domain and not subdomains, providing you have not submitted it to be preloaded into web browsers (please tell me you didn't preload it without fully understand what that entailed! - you can check this by running your main domain through the SSL Labs testing tool).

However, the world is moving towards HTTPS everywhere and your development environments do not reflect production. Some features (HTTP/2, Geolocation... etc.) will only work when using HTTPS and this list is growing. Also depending how you develop and reference resources you might start seeing mixed content warnings or missing content once you deploy to production. So in my opinion you DO need HTTPS in your development/QA environments. While I do not know your platform, you really are better figuring out how to set up HTTPS on your dev environments rather than trying to work around this. Self-signed certificates can be created for free and made to be trusted in your test environment so they are indistinguishable from real certificates to a select number of users.

Barry Pollard
  • 40,655
  • 7
  • 76
  • 92
  • 27
    "HSTS is not 'nasty' - it's a security feature" - its not "Nasty" unless you are trying to use the internet for something other than google's whitelisted set of purposes. Any "feature" like this should have a power user flag to turn it off completely. Its common sense. As it stands this "feature" turns simple development(scrape django metrics from this url) tasks into odysseys of the mind(can't securly connect to this address that you yourself host. You are probably trying to trick yourself so I'll step in and protect you form bad actor you. Hold your thanks, just doing my job" – nsfyn55 Mar 26 '18 at 20:15
  • 2
    @nsfyn55 Google didn't automatically flag your domain as HSTS. You or one of your team did. – DylanYoung Sep 30 '19 at 18:17
  • 9
    Its irrelevant where or who enforced HSTS. Any feature implemented in a browser should allow a power user to disable it. – nsfyn55 Oct 01 '19 at 16:17
  • Explain to me how you override CORS or allow use of SSLv2 or use HTTP/2 without HTTPS, or allows access to Geolocation data without HTTPS or any number of other security feature that the browser implements and doesn’t allow you to override? And btw you can override this if you want as detailed in the other answer but the way to do that is not advertised, supported or guaranteed not to change. – Barry Pollard Oct 01 '19 at 16:53
  • Developing on HTTPS is good. Forcing a whole domain and all subdomains onto HTTPS is painful. Disabling HSTS doesn't prevent anyone from using HTTPS in development. – Ryan Nov 05 '20 at 01:51
  • 7
    Dynamic HSTS is wreaking havoc on local development. It's very frustrating and wasting my time! – Josh M. Jan 24 '21 at 13:07
  • Exactly. @nsfyn55. I'm over here trying to debug a Cloudflare issue wreaking havoc on my API and I simply don't want to have to issue a certificate for a subdomain I use to bypass Cloudflare. The accepted answer works wonders to allow me to bypass my HSTS setting for this specific case. – Alexis Evelyn Jan 29 '21 at 02:14
  • 2
    This is an opinion not an answer – anataliocs Feb 25 '21 at 18:26
  • 1
    The middle paragraph gives the answer. The first paragraph refutes the “opinion” given in the question. And the third paragraph gives some more context as to why an alternative solution to the OPs issue might be better. – Barry Pollard Feb 25 '21 at 18:37
  • Google preloads HSTS on the entire .dev TLD and a bunch of others which makes it something some of us didn't actively choose. Frustratingly self-signed or Let's Encrypt Staging certs can no longer be easily 'accepted' in modern browsers. Bypassing HSTS in Chrome and Firefox is possible but extra challenging because of this. – Martijn Heemels Jul 20 '23 at 16:24
  • The above answer was written in 2017, before the .dev domain was introduced publicly (in 2019) and before registrars (including Google) started preloading full TLDs. However, since then, I'd argue my final paragraph has become even more relevant. If you've a domain at all then use HTTPS on it, if you don't need a domain then use 127.0.0.0 or localhost would be my advice. – Barry Pollard Jul 20 '23 at 17:39