HSTS not set everywhere

1

Sorry this is probably a very stupid question (I am not a coder) but why isn’t

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

set everywhere?
I copied www/conf/sites-available/05-dedyn.conf.var for my own server and noticed this.

https://github.com/search?q=repo%3Adesec-io%2Fdesec-stack%20add_header%20Strict-Transport-Security&type=code
2

What do you mean with “everywhere”?

Stay secure,
Peter

1 Like
3

Sorry, my mistake.
“preload” is not set everywhere and I was wondering why.

4

I don’t speak for Desec, but allow me to point out that this is in line with the recommendation:

Preloading Should Be Opt-In

If you maintain a project that provides HTTPS configuration advice or provides an option to enable HSTS, do not include the preload directive by default.

For the full explanation, see the HSTS Preload documentation. Note this statement in bold on that site:

HSTS preloading is not recommended.

1 Like
5

do not include the preload directive by default . We get regular emails from site operators who tried out HSTS this way, only to find themselves on the preload list without realizing that some subdomains cannot support HTTPS. Removaltends to be slow and painful for those sites.

I also don’t speak for desec, but I don’t think this is a problem for the desec.io domain :grinning:

6

The desec.io domain is included in the preload list.

1 Like
7

Right, that is why I was wondering why NGINX isn’t always set to preload.

8

The preload directive is only used to get the domain onto the HSTS preload list. It has no other purpose. The code repository shouldn’t have the directive, as that would cause other domains which use the code to unwittingly become preloaded. The directive is meant to be added by a server operator if and when a domain is ready and willing to be on the preload list. The web server for desec.io serves the header with the directive and the domain is listed, so what is lacking in your opinion?

1 Like
9

I might have a different understanding of how preload works.

Quote:

You must make sure your site continues to satisfy the submission requirements at all times. Note that removing the preload directive from your header will make your site immediately eligible for the removal form, and that sites may be removed automatically in the future for failing to keep up the requirements.

Here is how I understand the situation:
desec decided to preload. That is why it is best practice to use that preload everywhere in NGINX.

10

No. Preloading causes all subdomains to be HSTS-preloaded, but the preload directive only needs to be served on the base domain, see Submission Requirements Step 4.

In other words, setting preload on subdomains has no effect.

Stay secure,
Peter

3 Likes
11

That explains it, thank you! :blush: