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

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.

HTTPS Everywhere :: Using HTTP Strict Transport Security

The concept of HTTPS, that is having the web traffic from your browser to the web server over an encrypted channel is widely used over the web. It ensures that no attacker in the middle can grab or modify transmitted information like your cookie data; hence preventing the hijacking of your web session. So, enabling HTTPS limits the capability of an attacker in the middle.

How can Man-in-the-middle (MITM) attacker work around HTTPS ?

Mostly when users wants to browse a website, for instance say bank of america website, they would generally type “bankofamerica” or “www.bankofamerica.com” in their browser address bar. On this browser would basically make an HTTP request to bankofamerica.com i.e. http://www.bankofamerica.com, even though bank website operates as https://www.bankofamerica.com. So, to rectify that bank website can redirect the HTTP request to HTTPS (by issuing a 302 re-direct), but it still leaves your HTTP request to the bank, vulnerable to attack by MITM before the actual redirection happens. The SSL-stripping MITM attack introduced by Moxie Marlinspike in his 2009 BlackHat Federal talk “New Tricks For Defeating SSL In Practice“, exploits this vulnerability. It would be much more safer if the HTTP request can be totally avoided and the browser itself knows that it should connect to the website over HTTPS. This is exactly what HTTP Strict Transport Security (HSTS) is meant to address.

(See the pictorial representation of above explained vulnerability in the figures 1 and 2. Figure 1 shows the normal redirect mechanism of the browser request from HTTP to HTTPS and figure 2 shows that attacker can intercept the initial HTTP request before the redirect to establish himself as MITM)

url-redirect-mitm

figure 2: URL redirect with MITM

url-redirect-normal

figure 1 : 302 URL redirect scenario

How does HSTS operate?

HSTS support is implemented by adding a “Strict-Transport-Security” HTTP header to the server’s response, which will inform the browser that this website would connect only over HTTPS. Henceforth, any further HTTP request to website would be transformed at the client side/browser side itself into HTTPS, hence no network traffic goes over HTTP. So, sending:

Strict-Transport-Security: max-age=31556926;

would instruct the browser that the website sending this header should be accessed only over HTTPS for a year (as per max-age). Thus, the use of this header reduces the attack surface drastically: provided that the initial response (bootstrapping response) by the server reaches the browser without interception.

The website can take another step ahead and specify that all its sub-domains as well would be using HSTS by the use of “includeSubdomains” option as shown in the following example (though use of includeSubdomains is optional)

Strict-Transport-Security: max-age=31556926; includeSubdomains

Currently, HSTS has been implemented in Firefox, Chrome and Opera; though it is still to implemented in IE and Safari. The updated browser trends for HSTS and other features can be seen at BrowserScope.

(Apart from making the sub-domains oblige to HSTS policy, “includeSubdomains” has much more significance attached to it. This is covered in the next post here.)

Can we do something about HSTS Bootstrap MITM problem?

As we have seen that initial response from the web server which has the HSTS header should reach non-intercepted to the browser, in order to ensure complete security from adversary. This problem is referred to as Bootstrap MITM Vulnerability.

  1. One possible solution is to have a pre-loaded list of hosts in the browser for which HSTS would be on-by-default. Firefox and Chrome already support a pre-loaded list of hosts which want HSTS on by default. Chrome’s pre-loaded list can be seen here.
  2. Another potential solution is to include the HSTS information with DNSSec requests itself. Though, I have not come across any references which implement or mention details about it.

What HSTS is not meant for?

HSTS is not meant to prevent against:

  1. Phishing Attack: Rather, it complements many existing phishing defenses by instructing the browser to protect session integrity and long-lived authentication tokens.
  2. Malware: As malicious code executing on the user’s system can compromise a browser session, regardless of whether HSTS is used.

Note:- The HSTS specification published as RFC 6797 is based on the original work by Collin Jackson and Adam Barth as described in their paper “ForceHTTPS: Protecting High-Security Web Sites from Network Attacks.