Anatomy of “includeSubdomains” directive in HTTP Strict Transport Security Policy

In my previous post, I gave a general introduction to HTTP Strict Transport Security (HSTS) and this post would be a follow up to that, talking specifically about “includeSubdomains” directive used in HSTS policy. If you are not familiar with HSTS, I suggest you read the previous post here, before reading this post.

What is the significance of “includeSubdomains” ? (references RFC 6797)

In the absence of “includeSubdomains” directive the web application would be unable to protect its “domain cookie” in an adequate way, even though the host has its secure flag set. To understand this lets consider the following use case examples:

• Using HSTS without “includeSubdomains” directive

Suppose there exists a top-level DNS domain name for a website which is “anonymous.com” and a cookie is being set for the entire “anonymous.com”, this cookie is termed as “domain cookie”. Also, assume that the secure flag is set by the website (which actually means cookie can be sent only for HTTPS requests).

Now, here if an attacker manages to register a non-existing domain say https://notlisted.anonymous.com and manages to point the DNS entry to an existing  HTTP server under his control; this would mean the following:

1. The user’s browser (user agent) is unlikely to have any HSTS policy set for the domain, as it is some random sub-domain name introduced by the attacker.
2. And if the browser makes a request to the “notlisted.anonymous.com”, this will send an HTTP request and also include the secure flagged cookie (as the registered domain is HTTPS).
3. Assuming “notlisted.anonymous.com” presents a TLS certificate and the user clicks through it, this would lead to attacker obtaining the cookie [1].

• Using HSTS with “includeSubdomains” directive

Here, the web application at “anonymous.com” domain, makes use of HSTS policy along with “includesSubdomains” directive. As a result, the browser will enforce any subdomain, even attacker’s “notlisted.anonymous.com” to operate over HTTPS.

Thus, this would ensure adequate security for domain level cookie.

Issue of removing/disabling HSTS policy for sub-domain (references IETF draft message by Adam)

The usage of HSTS “includeSubdomains” lacks some clarity in terms of removal of HSTS policy for sub-domains. Consider the following scenario as depicted in figure 1:

figure 1: Removal of HSTS policy for sub-domain

• As shown in the figure 1, imagine the HSTS policy is first set for “facebook.com” along with the “includeSubdomains” directive, this will mean that all the sub-domains for facebook.com including “chat.facebook.com” needs to follow the HSTS policy.

• Now, following this if the subdomain “chat.facebook.com” sets the max-age = 0 header, it basically means remove any HSTS policy for “chat.facebook.com“.

• There are basically two course of action, firstly go for the MAX of expiration time {parent domain, sub-domain}, which would mean HSTS policy for the “chat.facebook.com” cannot be disabled and it would remain HSTS domain forever. (This might be a problem, if a sub-domain decides to move from HTTPS to HTTP but the naked domain is still HSTS.)

• Secondly, letting the sub-domain max-age =0 to act as “do not include in sub-domain inheritance”, which though seems to be reasonable but is not. As essentially the policy is set at parent domain i.e. the naked domain facebook.com and not at  sub-domain level. And letting the sub-domain to change the parent domain policy is not an appropriate approach.

Currently, Chrome’s implementation takes the first option; though there are possible work around to avoid sub-domain from being HSTS forever, there is no clean/clear way to handle it (even RFC doesn’t specify anything directly).

PS:- I am not sure how this is handled in Firefox or Safari, if you have any references please leave it as a comment.

——————————-End of Post ——————————————————

[1] It is possible, but not certain, that one may obtain a requisite certificate for such a domain name such that a warning may or may not appear.