问题：

通常人们google.com直接在浏览器的地址栏中输入而不包括http://或https://前缀。

在新的隐身会话中使用 Chrome DevTools，我运行了以下实验：

脚步：
-----------------
直接在
浏览器的地址栏。

 1. 请求：http://google.com；
    响应：状态代码：301 永久移动
              地点：http://www.google.com/
              缓存控制：公共，最大年龄=2592000

 2.请求：http://www.google.com；
    响应：状态代码：302 找到
              位置：https://www.google.com/?gws_rd=ssl

 3.请求：https://www.google.com/?gws_rd=ssl；
    响应：状态代码：200
              严格的传输安全：max-age=31536000

笔记： 
-----------------
* 要获得相同的结果，请开始新的隐身会话（关闭所有隐身会话 
  窗口并打开一个新窗口）。如果你已经有一个隐身窗口打开你
  可能不会得到相同的结果。检查“禁用缓存”也无济于事。

* 如果您在同一个隐身会话中重复实验，您会注意到 
  与第一次相比有以下不同：

    * 请求 1：如果“禁用缓存”未选中（模仿浏览器的
                 正常使用期间的行为），响应将来自缓存
                 由于“Cache-Control: public, max-age=2592000”响应
                 标头第一次返回。这意味着http
                 请求未发送（即使它仍然显示 301
                 响应）这可能是一件好事。

    * 请求 2：响应将是 307 而不是 302。这是由于
                 "strict-transport-security: max-age=31536000" 返回
                 第三次请求第一次。无论如何都是这种情况
                 是否选中“禁用缓存”。

* 一旦浏览器意识到域受 HSTS 保护（通过 
  HSTS 预加载或 STS 响应标头）浏览器将“内部”重定向
  该域对 https 的所有 http 请求。这些重定向显示在
  网络选项卡为“状态代码：307 内部重定向”（这是一种 
  误导，因为看起来响应来自服务器 
  现实这一切都发生在浏览器中。注意没有
  这些请求的“常规”部分中的“远程地址”

* 检查域是否受 HSTS 保护的另一种（可能更简单）方法是 
  在 https://hstspreload.org/ 中输入域，但有一些警告！ 
  https://hstspreload.org/ 为“www.google.com”报告以下内容：
     - “响应错误：响应中没有 HSTS 标头。”
     - “`http://www.google.com` 不会重定向到 `https://www.google.com`”
  这些发现都与网络中观察到的不一致 
  上面实验中的标签！我通过电子邮件发送了 hstspreload 邮件列表并
  收到以下有趣的响应：“服务器 
  http://www.google.com 并不总是将 http 重定向到 https，这就是为什么 
  出现错误。例如，如果我使用 curl，我不会得到重定向。”
-----------------

隐私/安全问题：

• 由于未包含在 HSTS 预加载列表中，因此初始请求google.com已完成。此请求容易受到 MITM 攻击。httpgoogle.com

• 浏览器在任何时候都不会重定向到https://google.com，因此永远不会为此域设置 STS 标头。这意味着即使未来的请求google.com也不会受到 HSTS 保护，因此可能容易受到 MITM 攻击！

  值得注意的是，初始 301 重定向中包含的缓存控制 max-age=2592000（30 天）响应标头确实提供了类似于 HSTS 提供的保护级别，因为它会导致http://google.com“内部”处理未来的请求通过缓存（重要的是重定向到受 HSTS 保护的“www.google.com”域）。另一方面，缓存控制 max-age设置为在 30 天后过期（比 HSTSmax-age通常设置的要短得多），最重要的是，与HSTS max-age不同，它在对启用 HSTS 的域发出的每个https请求时都会刷新，max age在发出新的不安全http请求之前，不会刷新缓存控制！这意味着您的请求google.com 可以每 30 天拦截一次。

• 请求www.google.com是通过 http 发出的，并且容易受到 MITM 攻击。至少在这种情况下，响应是https://www.google.com包含 STS 标头的 302 重定向。这意味着任何后续请求都http://www.google.com将被浏览器“内部”重定向到 https，如上所述，HSTSmax-age在每个请求上都会刷新。因此，只要您的浏览器https://www.google.com每年至少发出一次请求（这是 STSmax-age到期设置的时间），对该域的所有请求都将受到 HSTS 保护。

TL;DR - “google.com”不受 HSTS 保护，似乎请求可能每 30 天一次（或者如果缓存被清除或使用隐身模式更频繁）受到 MITM 攻击。

这可能不像听起来那么糟糕，原因如下：

• 所有重要的 cookie.google.com并且www.google.com肯定都secure设置了标志。
• google.com似乎只是重定向到，www.google.com因此任何请求google.com实际上都只会是根路径（因此窃听者不会对 URL 本身感兴趣）。
• 发送/接收更敏感数据（例如 gmail.com、accounts.google.com...）的 Google 子域位于 HSTS 预加载列表中。因此，即使攻击者设置了 sslsplit 之类的东西，并且用户最终受到攻击者的控制http://www.google.com（这已经足够难以拉动，因为它要求用户不要注意到丢失的挂锁图标），HSTS 预加载的域仍然会受到保护. 因此，攻击者需要阻止用户导航到任何这些子域。

问题

1. Google 未启用 HSTS 的原因可能是什么 google.com
2. www.google.comGoogle 仅启用 STS 标头但未将该域添加到 HSTS 预加载列表的原因可能是什么？