2

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?

| improve this question | | | | |
  • 3
    google.com isn't a top-level domain; it's a second-level domain. com is the top-level domain. – Joseph Sible-Reinstate Monica Jan 20 at 19:39
2

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).

| improve this answer | | | | |
  • 3
    The fact that there is no confidential data doesn't really matter. The point (well, one main point) of HSTS is to protect against SSL Stripping. If a user types google.com into their browser's address bar, and an attacker intercepts that HTTP request, they may be able to trick the user into thinking they are on google.com when they are not. This might further lead to launching a fake login prompt and phishing the user for their email/password. – Conor Mancone Jan 20 at 21:09
  • "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." -- I'm sure you're right. I just wanted to confirm that Google's stated reasons -- "We want to support HTTP clients" and "We don't have HTTPS implemented on all subdomains" -- made no sense. – Bennett Jan 21 at 1:40
  • "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." -- Maybe, but I'll just add, that would be just as much reason not to send the Location: header redirecting the user from the http:// URL to the https:// URL. But they do that. – Bennett Jan 21 at 2:07
  • @Bennett as I said above, they do not send the redirect header for certain browsers, depending on the UA string. – averell Jan 21 at 12:18
  • @averell right I understand that. To word my assertion more precisely: For any user-agent where Google is serving the Location: header to redirect to an https:// url (thus, Google trusting that the user-agent can handle https), Google should also serve the strict-transport-security header (without the includeSubDomain) attribute. It improves security and there is no good reason not to do it. (In the worst case, the browser will ignore it.) Would you agree or disagree with that statement? – Bennett Jan 22 at 22:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.