Question

为什么google.com没有在http严格的传输安全响应标头上设置includeSubDomains指令？

google.com HSTS共鸣标题类似于：

id l email l sms l tel l mail
----------------------------
1    40       20   30    50
2    20       30    40   50 
2  ........................
3 ..............etc

为什么不

id l date_month l email l sms l tel l email
--------------------------------------------------
1    2017/01      20       10    5    2
1    2017/02      ..............
.
2    2017/01   .............
2    2017/02  ................
.
etc

第二个应该离我更安全，是吗？

Answer 1

这是静态的

使用谷歌浏览器，您可以转到chrome://net-internals/#hsts并查询不同的域。输入google.com并单击“查询”将返回结果列表。

在该结果列表中，您可以看到static_sts_include_subdomains为true且dynamic_sts_include_subdomains为false。这比动态设置更好，这很容易受到攻击，因此浏览器第一次通过http://（不是https://）请求域拦截通信。为了克服这个弱点，我们有静态模式，允许将HSTS记录直接硬编码到浏览器的源中。

希望这有帮助

Answer 2

是的，使用includeSubDomains更安全。

例如，攻击者可以设置并使用子域名（例如hacked.google.com）并通过HTTP访问该域名，并使用它来访问或覆盖在顶级域名（google.com）设置的Cookie，即使该顶级域名也是如此级别域由HSTS保护。当然，如果您在Cookie上使用Secure属性，那么这可能不是问题，但这只是使用includeSubDomains的原因的一个示例。

除非所有子域在HTTPS上都可用（显然），否则无法设置includeSubDomains attrribute。因此，如果Google拥有blog.google.com并且仍未将其升级到HTTPS，则可能会解释为什么他们不会在顶级域名中使用includeSubDomains。

然而，正如@Horkine正确指出的那样，Google将其域名预加载到Chrome浏览器代码中（并且其他浏览器也会预读该预载列表），因此这个HTTP标头不会用于现代浏览器。

Weirldy预加载版本和HTTP HTTP Headers版本之间存在一些不一致之处。说实话，这很奇怪。顺便提一下，这些差异也是breaks their own rules for preloading。

<强> www.google.com

www.google.com 的预加载版本确实具有 includeSubDomains属性。
严格传输安全HTTP标头版本不具有includeSubDomains属性，但不具有preload属性。

<强> google.com

google.com 的预加载版本确实 includeSubDomains属性
不发布Strict-Transport-Security HTTP标头。

为什么这些不一致？我们只能猜测：

在升级到所有网站后，他们可能永远不会更新他们的HTTP标头？
或者可能是因为某些应用程序对较旧的浏览器进行浏览器检测（不包含预加载代码，但确实理解HSTS标头）并且由于某种原因将旧浏览器重定向到http://old.google.com
或者它可能是特定于地区的？

所有这一切都是猜测，因为只有Google可以回答，而且我不知道他们在自己网站上使用的内容或原因的任何文档。

但是，是的，为了回答你最后一个问题，包括includeSubDomains（如果可能的话）更安全，预加载更安全（尽管不是没有风险，除非你100％确信你只是使用HTTPS）。

为什么google.com没有在HSTS响应头上设置includeSubDomains指令？

2 个答案: