0

Referencing this: https://hstspreload.org/

There's a bunch of stuff about making really sure that it all works before you get them to pre-load it:

  • when testing first test with a max-age of 5 minutes, then ramp up to 1 week, & 1 month.
  • They say if you're making a framework or library, then make preload be opt-IN.

I assume that this is mainly about people retro-fitting preloaded HSTS to existing systems, and then discovering that some legacy part of the system doesn't support HTTPS?

I'm creating a greenfield site in .NET Core (hosted on Azure). I think I should be able to develop everything in my site, in such a way that it supports HTTPS.

Are there any common bits of functionality or .NET /.NETCore libraries that don't support HTTPS, and thus might cause me a problem if I configured the preload up-front?

Very similar question, with a more SecurityTheory-targetted angle posted in the InformationSecurity Exchange: https://security.stackexchange.com/questions/201328/is-there-any-conceptual-downside-to-enabling-preloaded-hsts-on-greenfield
Brondahl
  • 7,402
  • 5
  • 45
  • 74

1 Answers1

0

Only you can answer this based on your site. Remember HSTS works at a whole domain and preload basically demands all sub domains too.

So if www.example.com is all HTTPS but blog.example.com, or intranet.example.com still has not migrated to HTTPS the preloading will suddenly break this and require an immeasurable HTTPS implementation.

The other issue is you might not notice this until it comes into affect and it’s too late. Especially if you use the www variant and so the browser never sets HSTS at the top level domain until you preload this. To get around this it is recommended to load at least one asset from the top level domain on your website (e.g. https://example.com/logo.png) and also set a long max-age and check neither causes problems for a while before preloading.

Adding to the preload list is basically irreversible, and is completely out of your control, which is why I do not like it even though I fully support an HTTPS only web and agree that preload is the only real way to securely enforce that for a domain. This Chrome bug is littered with people asking to be removed from the preload list after discovering they weren’t ready for it.

More thoughts on my blog post: https://www.tunetheweb.com/blog/dangerous-web-security-features/

Barry Pollard
  • 40,655
  • 7
  • 76
  • 92