isn't it a security gap if TLD hostname doesn't send the strict-transport-security header?

Question

If you connect to https://google.com (without www.) you get a HTTP 301 redirect to https://www.google.com/ . Then if you connect to https://www.google.com/ the response includes the strict-transport-security header.

I contend this is a (small) security gap, because the strict-transport-security attribute never gets set for the top-level hostname, google.com. This means that no matter how many times the user has connected to google.com or www.google.com, if an attacker manages to send them to http://google.com/ , and the attacker is a man-in-the-middle who can redirect google.com to a site the attacker controls, they can eavesdrop on the connection. (Also, Google's entry on the HSTS preload list only applies to www.google.com, not google.com.)

However, Google is rejecting all reports of "security holes" regarding HSTS: https://sites.google.com/site/bughunteruniversity/nonvuln/lack-of-hsts with the statement "Migrating all the domains to HTTPS, and deprecating all clients that can only talk over plaintext HTTP takes time."

I contend these objections makes no sense. If a client only speaks http, then the way to continue supporting that client is to continue serving http. But if you serve the STS header over https connections, you're telling the client, "Hey client, since you obviously speak https, this host promises it will always serve you https in the future and you should always make https requests to me." The only valid reason not to serve the STS header would be if you think the hostname might some day not support https any more, which is hopefully not the case for google.com!

Perhaps there are subdomains of google.com that don't support https. But then google.com can just serve the STS header without the "includeSubDomains" attribute, so it won't be applied to subdomains.

So I maintain that: 1) Not serving the STS header for the hostname google.com is a security gap. While it's a small gap, there is no offsetting legitimate reason not to serve the header. 2) It is not a valid objection that they "want to keep supporting clients that only talk over plaintext HTTP". 3) It is not a valid objection that they have not migrated other subdomains to https yet.

Am I missing something?

Answer 1

First off, it is apparently more complicated: A bit of testing reveals www.google.com will, apparently, only send the HSTS header if it sees a user agent string that indicates a modern browser. Without a user agent string, e.g. with curl -H https://www.google.com, you will not receive a HSTS header at all. In fact, the google search page will still work via http if it doesn't see a modern browser's user agent string.

Google obviously still wants to support plain http access to that page, and not force certain browsers to https. I'm not sure why, but they might want to support some old, broken clients which would actually recognise the HSTS header but would fail to connect due to a broken SSL/TLS implementation.

The security risk to google itself is actually zero (as there is no confidential data on the search page), though there is a small risk to the user that a search term is exposed.

Other google domains like mail. that are on the browser preload lists and therefore always secured in practice.

The reason that Google is rejecting reports for missing HSTS? That has nothing to do with wether Google thinks that it should be fixed. Bluntly put: They are working on HSTS and they already know that it is not there. It doesn't help them if people report what they already know, so they aren't going to hand out rewards for that.

They may still fix the problem in the future, but until then they don't want to deal with a lot of folks reporting the same thing over and over again (and demanding a reward).