Oftentimes people enter
google.com directly in the browser's address bar without including either the
Using Chrome DevTools on a fresh incognito session, I ran the following experiment:
STEPS: ----------------- Enter "google.com" (or equivalently "http://google.com") directly in the browser's address bar. 1. Request: http://google.com; Response: Status Code: 301 Moved Permanently Location: http://www.google.com/ Cache-Control: public, max-age=2592000 2. Request: http://www.google.com; Response: Status Code: 302 Found Location: https://www.google.com/?gws_rd=ssl 3. Request: https://www.google.com/?gws_rd=ssl; Response: Status Code: 200 strict-transport-security: max-age=31536000 NOTES: ----------------- * To get the same results, start a fresh incognito session (close all incognito windows and open a new one). If you already have an incognito window open you might not get the same results. Having "disable cache" checked won't help either. * If you repeat the experiment from the same incognito session, you'll notice the following differences from the first time around: * Request 1: If "disable cache" is unchecked (which mimics the browser's behavior during normal usage), the response will be from cache due to the "Cache-Control: public, max-age=2592000" response header returned the first time around. This means that the http request is not sent out (even though it still shows a 301 response) which is probably a good thing. * Request 2: The response will be a 307 instead of 302. This is due to the "strict-transport-security: max-age=31536000" returned by the third request the first time around. This is the case regardless of whether "disable cache" is checked or not. * Once the browser becomes aware that a domain is HSTS protected (either via the HSTS preload or the STS response header) the browser will "internally" redirect all http requests to https for that domain. These redirects are displayed in network tab as "Status Code: 307 Internal Redirect" (which is kind of misleading since it looks like the response is coming from a server when in reality its all happening within the browser. Notice that there is no "Remote Address" in the "General" section for these requests * Another (perhaps easier) way to check if a domain is HSTS protected is by entering the domain in https://hstspreload.org/ but there are caveats! https://hstspreload.org/ reports the following for "www.google.com": - "Response error: No HSTS header is present on the response." - "`http://www.google.com` does not redirect to `https://www.google.com`" Neither of these findings is consistent with what is observed in the network tab in the above experiment! I emailed the hstspreload mailing list and received the following interesting response: "The server for http://www.google.com doesn't always redirect http to https, which is why this error appears. E.g. if I use curl, I don't get the redirect." -----------------
The initial request to
google.comis made over
google.comis not included in the HSTS preload list. This request is vulnerable to MITM attacks.
At no point is the browser redirected to
https://google.com, therefore the STS header is never set for this domain. This means that even future requests to
google.comwill not be HSTS protected and may therefore be vulnerable to MITM attacks!
It's worth noting that the cache-control max-age=2592000 (30 days) response header included in the initial 301 redirect does seem to provide a level of protection similar to what HSTS provides since it causes future requests to
http://google.comto be handled "internally" by the cache (and importantly redirected to the HSTS protected "www.google.com" domain). On the other hand, the cache-control
max-ageis set to expire after 30 days (much shorter than what the HSTS
max-ageis usually set to) and, most importantly, unlike the HSTS
max-agewhich is refreshed on every
httpsrequest made to an HSTS enabled domain, the cache-control
max ageis not refreshed until a new insecure
httprequest is made! This means that your requests to
google.comcan be intercepted as often as once every 30 days.
The request to
www.google.comis made over http and is vulnerable to MITM attacks. At least in this case the response is a 302 redirect to
https://www.google.comwhich does include the STS header. This means that any subsequent requests to
http://www.google.comwill be "internally" redirected to https by the browser, as noted above, the HSTS
max-ageis refreshed on every request. So as long as your browser makes a request to
https://www.google.comat least once a year (which is what the STS
max-ageexpiry is set to), all requests to that domain will be HSTS protected.
TL;DR - "google.com" is not HSTS protected and it seems as though requests can potentially be subject to MITM attacks as often as once every 30 days (or more often if cache is cleared or incognito mode is used).
This may not be as bad as it sounds for the following reasons:
- All important cookies for
www.google.commost definitely have the
google.comseems to do nothing more than redirect to
www.google.comso any request to
google.comwould realistically only be to the root path (Therefore the URL itself wouldn't be interesting to an eavesdropper).
- Google subdomains that send/receive more sensitive data (e.g. gmail.com, accounts.google.com...) are on the HSTS preload list. So even if an attacker sets up something like sslsplit and a user ends up on an attacker controlled
http://www.google.com(which is already hard enough to pull of as it requires the user not to notice the missing padlock icon), the HSTS preloaded domains would still be protected. An attacker would therefore need to prevent a user from navigating to any of those subdomains.
- What could be the reasons why Google hasn't enabled HSTS for
- What could be the reasons why Google has only enabled the STS header for
www.google.combut hasn't added that domain to the HSTS preload list?