Track down sites suggesting to blindly preload

[lgarron]

Latest one:

• https://docs.nextcloud.com/server/9/admin_manual/configuration_server/harden_server.html#enable-http-strict-transport-security

[lgarron]

https://github.com/roots/trellis defaults to preload. I've filed a bug at https://github.com/roots/trellis/issues/727

[lgarron]

PR set to twitter/secureheaders at https://github.com/twitter/secureheaders/pull/310

[lgarron]

The hstspreload.org site now also has a section about this: https://hstspreload.org/#opt-in

[lgarron]

https://www.section.io/blog/using-varnish-to-tweak-your-http-responses/

The relevant gist is owned by @section-io-gists

[glennslaven]

Hi @lgarron,

Thanks for pointing this out, we've updated the gist to remove the preload directive.

[lgarron]

Thanks for pointing this out, we've updated the gist to remove the preload directive.

Looks good, thanks! (You may also want to remove the trailing semicolon, but that doesn't affect correctness.)

[graingert]

@lgarron maybe the header should be changed to:

preload, SHA3(`${domain} I have read and understood https://hstspreload.org/#information`)

[lgarron]

@lgarron maybe the header should be changed to:

Then someone will find a way to automate it and shoot their users in the foot. :-P

More seriously, a site-specific confirmation is not a bad idea, but

1. it requires extra configuration for infrastructure shared across multiple hosts (a specific value per host, instead of ≈ a boolean)
2. It requires changing the header convention. This is a non-trivial change in semantics; I don't want to change or add anything other than preload without a spec.
3. It requires us to figure out what to do for the special case of old domains.

It would probably be a good idea to discuss this at a meetup this year, which I would like to organize again once we've automated scanning and pruning.

[lgarron]

@graingert: Actually, would you mind filing a separate issue for that idea, so we can keep track of any progress on it in one place?

[graingert]

@lgarron 1. no because you can provide a set of SHA3(domain + edu-nonce) and as long as your domain is in the set you win

win = preload

[graingert]

Those that know enough to automate it, know not to

[lgarron]

@lgarron 1. no because you can provide a set of SHA3(domain + edu-nonce) and as long as your domain is in the set you win

Bloating headers is not a good idea. :-/

[graingert]

HPACK means it's fine

[lgarron]

HPACK means it's fine

I don't think this is an appropriate assumption to make on behalf of all sites and clients.

In any case, I think a single hash for just the current domain is reasonable to ask for, and rolling it out won't be any harder from our end.

[lgarron]

Talks about preloading but doesn't mention how to submit to the list: https://blog.stackpath.com/glossary/hsts/

[lgarron]

https://varvy.com/pagespeed/hsts.html

[Malvoz]

I think https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security could need some clarification around preload and the submission list.