How to disable Chrome HSTS permanently for a subdomain

Question

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?

Vannie

Answer 1

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

Pipistrelle

This will permanently whitelist the website. How do I undo this? – Hengist

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. – Jobbery

#35275159 – Ahoufe

@FranklinYu click on the certificate (padlock) in the address bar and click "Re-enable warnings" – Concierge

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! – Unblinking

WHERE do you type this? Do you just click on the screen and type these letters? I tried and no effect – Dangerfield

@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 – Pipistrelle

I can confirm this still works on latest Chrome Dev – Memorize

@DanielWilliams try refreshing the page after typing in the letters. Still works for me on latest Chrome stable – Okajima

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). – Vinegarroon

Still works in december '23. Any equivalent for firefox? – Developer

OMG I can't believe this is real! – Fideliafidelio

Answer 2

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.

Many

Answer 3

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.

Ahoufe

"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" – Korten

@Korten Google didn't automatically flag your domain as HSTS. You or one of your team did. – Ekaterinoslav

Its irrelevant where or who enforced HSTS. Any feature implemented in a browser should allow a power user to disable it. – Korten

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. – Ahoufe

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. – Superhighway

Dynamic HSTS is wreaking havoc on local development. It's very frustrating and wasting my time! – Underthecounter

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. – Silverside

This is an opinion not an answer – Epicedium

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. – Ahoufe

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. – Firenze

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. – Ahoufe

HSTS also creates a chicken-or-egg problem with OCSP, if you want to take full advantage of HSTS by pre-loading, which is a nice efficiency/latency boost for HTTP, since browsers that respect it (all major modern browsers, at this time) won't first try HTTP and have to be redirected to HTTPS, wasting another round trip and server-side & network resources. Google won't preload unless you do it at the root of your domain. So, to have a public OCSP responder for your own PKI, you need a second domain or raw IP in the OCSP URL. HSTS pre-load needs an exception parameter or something. – Bust

Answer 4

I had the same problem. Chrome keep changing my dev site's http to https. But works on Microsoft Edge. Then found this solution:

From chrome > Settings > Privacy and security > Site settings > (click on your QA site) develop.app.domain.de > Insecure content > allow

Maunder