HSTS: Is includeSubDomains on main domain sufficient?

Question

In my Plesk web admin edition I just activated HSTS on my main domain www.domain.tld with

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

The test on ssllabs.com says that everything works fine. The problem is my subdomain (subdomain.domain.tld). If I test my subdomain on ssllabs it says that there is no HSTS activated.

Should I include the header

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

on my subdomain too or is an implementation on my main domain sufficient?

I thought by adding includeSubDomains there was no need for adding it explicitly on subdomains.

Answer 1

The includeSubDomains part only instructs the browser, once its seen it, that requests to other sub-domains should abide by the same HSTS rules (i.e; a valid certificate must be present). It doesn't "infer" the application of this rule to your sub-domains, if for instance a user has never accessed your www.domain.tld site before. In this case, their browser will never have seen the presence of this header on your www sub-domain, and thus will not apply HSTS rules.

If a user has seen this header on your www sub-domain, then tries to access a sub-domain with an invalid certificate, it will block it and prevent the user from continuing.

In short, you need to ensure that you serve the same HSTS header across all your sub-domains in order for this to be 100% effective.

Answer 2

Unlike say CAA, HSTS is not read from all the parent domain(s).

So if you have it set on example.com with includeSubDomains then it will not be read if you just visit www.example.com. However, if you happen to visit example.com first then it will be set. So basically you could get inconsistent results.

This is presumably because there would be performance (and privacy!) impact to check all the parent domain(s) to see if they also send a HSTS header with includesubdomains.

So it should be set on the domain used as well as any parent domain(s).

Now even that is often not enough to give full protection. For example if you sent it on www.example.com and on example.com but example.com is not usually visited then most web site visitors will only have the www variant cached as a HSTS domain. So it may well be possible to visit example.com over HTTP for at least one request. For this reason it is recommended to load one asset (e.g. an image) from your base domain over HTTPS when visiting your www domain - so that both HSTS policies are loaded. It is also recommend to redirect as example.com -> https://example.com -> https://www.example.com rather than example.com direct to https://www.example.com to pick up any example.com HSTS policy despite the performance impact of that extra redirect.

And it is possible to have different policies at each level. For example if you have some sub domains which are not on HTTPS (e.g. intranet.example.com) then you can have a HSTS policy at top level with no includeSubDomains and a different HSTS policy at www.example.com with includeSubDomains.

The alternative to all this is to preload the domain. This hardcodes the whole domain (and usually all sub domains) in the browser code so even first visits are protected. This also doesn’t have the performance impact of checking up all the parent domains so does take effect with only one entry with includeSubDomains. But preloading is a serious commitment and should not be entered into lightly as its basically irreversible. Also you cannot preload unless all your subdomains are HTTPS - we’ll at least without asking for special preloading. Another reason to load an image from top level domain so the base policy is picked up before any irreversible preloading takes effect!

All in all, it’s complicated! :-) But worth the effort to understand it and get it right.