why google.com not set includeSubDomains directive on HSTS response header?

2
votes

why google.com not set includeSubDomains directive on http strict transport security response header ?

google.com HSTS resonse header is something like:

Strict-Transport-Security:max-age=86400

Why not 

Strict-Transport-Security: max-age=86400; includeSubDomains

The second one should be more secure from my side, is that right ??

2
httpsecurityhttpresponsehsts

2 Answers

1
votes

It is static

Using Google Chrome, you can go to chrome://net-internals/#hsts and Query different domains. Entering google.com and clicking on Query will bring back a list of results.

In that result list, you can see that static_sts_include_subdomains is true and dynamic_sts_include_subdomains is false. This is better than setting it dynamically, which is vulnerable to an attack whereby the very first time the browser requests the domain with http:// (not https://) an adversary intercepts the communication. In order to overcome this weakness we have the static mode which allows for hard-coding HSTS records directly into the browser's source.

Hope this helps

1
votes

Yes it is more secure to use includeSubDomains.

For example an attacker could set up and use a subdomain (e.g. hacked.google.com) and access that over HTTP and and use that to access or override cookies set at top level domain (google.com) even though that top level domain is secured with HSTS. Of course if you're using Secure attribute on your cookies then this might not be an issue but this is just one example of why to use includeSubDomains.

You cannot set the includeSubDomains attrribute unless all subdomains are available on HTTPS (obviously). So if Google had blog.google.com and had still not upgraded this to HTTPS then that might explain why they would not use includeSubDomains at the top level domain.

However, as @Horkine rightly points out, Google preloads their domains into the Chrome browser code (and that preload list is also picked up by other browsers) so this HTTP header isn't used for modern browsers.

Weirldy there are some inconsitencies between the preloaded version and the HTTP HTTP Headers version. That is very odd to be honest. Incidentally these discrepancies also breaks their own rules for preloading.

www.google.com

  • The preloaded version for www.google.com does have the includeSubDomains attribute.
  • The Strict-Transport-Security HTTP Header version does not have the includeSubDomains attribute but not the preload attribute.

google.com

  • The preloaded version for google.com does have the includeSubDomains attribute
  • No Strict-Transport-Security HTTP header is published.

Why these inconsistencies? We can only guess:

  • It could be that they never got round to updating their HTTP Header after finishing the upgrade to all their sites?

  • Or it could be because some of the apps do browser detection for older browsers (which do not include the preload code, but does understand the HSTS header) and redirects older browsers to http://old.google.com for some reason?

  • Or it could be region specific?

All of it is a guess really, as only Google can answer and I'm not aware of any documentation of what they use on their own site or why.

But, yes, to answer you last question it is more secure to include includeSubDomains (if possible) and it is even more secure to preload (though not without risks unless you are 100% confident you are only using HTTPS).