Allow configuration of/turn off "IncludeSubdomains" option on HSTS for headers sent for external domains

(first post here, thanks, by the way, for such a cool product and community. I am really delighted by what has been built here – so fun!).

First, let me describe the problem I’m trying to solve:

I have pointed my base domain (in this case, agaskar.com) at omg.lol with a wildcard cert.
I also use my base domain (agaskar.com w/ both public/private addresses) to route a number of subdomains to little services I run.

I believe that the response by omg.logl being sent for my base domain includes headers that force HTTPS upgrade (see attached). This is great for domains I wish to end up here! TLS is great! Yay!

However, this is a huge pain when I’m trying to access services I run that I have not yet bothered to set up HTTPS for.

Basically, the fun flow I experience is:

  1. Try to visit my service at http://myservice.agaskar.com.
  2. Get redirected to https://myservice.agaskar.com, which doesn’t respond.
  3. Argh! Go to vivaldi://net-internals/#hsts and delete the HSTS cache for agaskar.com.
  4. Visit http://myservice.agaskar.com, yay, it works!
  5. UNTIL, i visit any domain that is redirected to agaskar.com and then the HSTS cache is recreated, and I get to start back at 1.

I’ve done some looking into it, and so far I have not found a to whitelist specific subdomains to stop them from auto-upgrading to HTTPS (Chromiums do allow the setting of a HSTSPolicyBypassList which prevents upgrade, but only for STATIC HSTS, so not the kind of HSTS we’re dealing with here).

On some level, I think this is a Chromium browser behavior problem, and when I get a moment, I’ll dig through their bug archives and maybe contribute a feature request over there.

I think turning the includeSubdomains off entirely may be reasonable and not affect existing behavior for anyone, based on the following rationale (where I make several assumptions about how HSTS works that I have not validated, fwiw):

if every page omg.lol serves has a HSTS header, then I get auto-upgrade for any subdomain that I want to direct to an omg.lol service (this is good). e.g.: agaskar.com has an HSTS (with no include subdomains) – it gets upgraded.

my-subdomain-that-goes-to-omg-lol.agaskar.com returns a page that ALSO has an HSTS – for that subdomain – it gets upgraded! That’s good.

my-personally-served-service.agaskar.com returns a page with NO HSTS. This is good, because as I mentioned above I’m a bad person and didn’t set up TLS/HTTPS.

I think the only folks this change would impact is people who are somehow relying on omg.lol setting an HSTS that somehow applies to one of their subdomains hosted elsewhere. I think it’s probably reasonable that these people handle their HSTS needs wherever that service is hosted, however, vs. relying on HSTS settings on the base domain (but if that’s unreasonable, maybe a simple flag that can control the on/off of includeSubdomains would be a good – albeit more expensive to implement – middle path?)

1 Like

Same here, I ended up…

  1. Set up a Cloudflare Worker (yes, some might say ‘uh… Cloudflare…’ but I just needed quick and dirty hack)
  2. Set Worker to proxy omg.lol content
  3. Rewrite header while proxying, replacing HSTS (though, for me, to remove preload, not to remove includeSubdomains.)

I have few apex domain hosted on omglol, and I might have to find some other thing (sorta looking at caddy to sit as a middleware? dunno right now…) I don’t use preload because I… just don’t know if I wanna do weird http thing… so.

1 Like

I’m 99% sure that I configured this for the sole purpose of getting some kind of website security evaluation thing to turn a red or yellow blip into a green blip, and clearly without a lot of consideration to the possible downstream impacts. Will get this fixed after work today, and I’ll follow up here once that’s done!

1 Like

oh, hm, it sounds like … maybe preload should be removed as well? That could result in someone getting their site unintentionally “cached” as desiring an https upgrade when they might want to change it later (I’m not sure I 100% understand the preload directive, but in what I was able to gather in the last minute or so it sets the domain up for inclusion in some canonical list … although maybe additional registration is required anyways so it doesn’t matter?).

Will get this fixed after work today, and I’ll follow up here once that’s done!

:heart: !

1 Like

I’ve just removed includeSubDomains and preload, so we should be all set now. Thanks for the suggestions! And sorry for the trouble. :+1:

1 Like