HSTS IncludeSubDomains – Is It Sufficient for Main Domain?

hstsplesksslssl-certificatesubdomain

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.

Best Answer

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.

Related Solutions

Hsts on main port 80, not on other ports

Yes, this is intentional. RFC 6797 states:

     The UA MUST replace the URI scheme with "https" [RFC2818], and

     if the URI contains an explicit port component of "80", then
     the UA MUST convert the port component to be "443", or>>

     if the URI contains an explicit port component that is not
     equal to "80", the port component value MUST be preserved;
     otherwise,

     if the URI does not contain an explicit port component, the UA
     MUST NOT add one.

     NOTE:  These steps ensure that the HSTS Policy applies to HTTP
            over any TCP port of an HSTS Host.

You should run plain HTTP services on a different domain, or even better, use a HTTP+TLS server as a reverse proxy to the internal plain HTTP service.

HSTS – How Does HSTS Handle Mixed Content?

HSTS doesn't try to handle mixed content at all: it just controls whether the browser should perform an internal 307 redirect to HTTPS whenever it tries to load HTTP URLs, or not. The mixed content warning is a feature of the browser, and all the current browsers do it (Mozilla Firefox 23+, Google Chrome 21+, Internet Explorer 10+, Edge from the beginning...). The mixed content warning blocks e.g. <script> and <iframe>, but not <img>.

The mixed content warning on all the browsers mentioned is checked before loading any content at all, i.e. before HSTS redirects, too. This seems only natural, and is also easy to test. By default, all external images are loaded even using plain HTTP, and a mixed content warning is given only for scripts and iframes.

HSTS only changes the situation where an image from an HSTS enabled domain is loaded using plain HTTP, and 307 Internal Redirect is performed. Worth noting: this is a situation with no mixed content warnings involved.

Therefore, HSTS does not work as a quick fix for the mixed content problem:

You need to fix http:// URLs on your site even for the domain itself.
You need to ensure that you don't load external scripts from sources you don't trust.
- If the third party doesn't enable HSTS, it's still vulnerable to man-in-the-middle attacks.
- Third parties might load content from further external sources, and all this applies to those, too.
- The external content site might be cracked or do malicious activities by themselves.

Best Answer

Related Solutions

Hsts on main port 80, not on other ports

HSTS – How Does HSTS Handle Mixed Content?

Related Topic