来自 IETF 草案 [ https://datatracker.ietf.org/doc/html/draft-ietf-websec-strict-transport-sec-06 ]：

10.1 HSTS 策略过期时间注意事项

服务器实现和部署网站需要考虑他们是否将过期时间设置为未来的常数值，例如，通过不断地向 UA 发送相同的 max-age 值。

例如，max-age 值为 778000 是 90 天：

Strict-Transport-Security: max-age=778000

请注意，UA 每次收到此标头都将要求 UA 更新其何时必须删除其对该已知 HSTS 主机的知识的概念。如何实现这一点的细节超出了本规范的范围。

或者，他们是否正在设置一个固定时间点的到期时间，例如，通过发送表示直到到期时间的剩余时间的 max-age 值。

这里需要考虑的是部署者是否希望发出信号的 HSTS 策略到期时间与网站域证书的到期时间相匹配。

此外，服务器实施者应考虑在其部署配置系统中使用默认的 max-age 值为零。这将要求部署者故意设置 max-age 以让 UA 为其主机强制执行 HSTS 策略，并保护他们免于无意中启用具有任意非零持续时间的 HSTS。

因此，由于浏览器将更新它存储的 HSTS max-age 在每个 [通过 https] 接收的 max-age 标头上，因此更长的时间不会真正导致八卦谈论的任何这种糟糕的缓存恐怖故事。唯一的问题是证书是否更改。但是，站点所有者应该意识到这一点，并且应该在证书到期之前（一整天左右）完成更改之前将 max-age 设置为低（5-8 分钟）。但是，这只是为了处理传入的证书过期（这主要是通过在最后一分钟之前用新证书替换证书来避免），如下所示：

14.6 假根 CA 证书网络钓鱼加 DNS 缓存中毒攻击

如果攻击者可以说服https://bank.example.com（受 HSTS 策略保护）的用户安装他们自己版本的根 CA 证书，声称是 bank.example.com 的 CA，例如，通过带有此类证书链接的网络钓鱼电子邮件。然后，如果他们可以对用户的 DNS 进行攻击（例如，通过缓存中毒）并为他们的虚假 bank.example.com 站点启用 HSTS 策略，那么他们自己就有了一些新用户。

这表明除非证书出现问题（验证警告或错误），否则在浏览器的 HSTS“会话”中间更改证书不会导致问题。这将使您的问题的全部意义变得毫无意义，因为它假定浏览器存储一些与与 HSTS 标头响应一起发送的证书相关的信息，以针对 HSTS 主机进行验证。由于草案没有提到这个概念，我想说这是一个无效的假设。

但是，可以通过公钥固定来存储要用于 HSTS 主机的证书信息。但这将在“工厂”级别或由用户手动完成，因此也无法通过 HSTS 主机进行更新。[更多信息请参见 http://www.imperialviolet.org/2011/05/04/pinning.html]

要回答您的最后一个问题，使用 HSTS 跟踪用户存在隐私问题。它通过使用 javascript 检查枚举的网站列表中的资源是否通过 https 加载，即使它被指定为 http。在这种情况下，具有适度低的 max-age 的目的是清除条目，以便阻碍用户跟踪。[有关更多信息，请参见 http://haxsys.net/2011/04/the-double-edged-sword-of-hsts-persistence-and-privacy/]

@Jesper Mortensen：HSTS 导致浏览器在发送之前将所有 http 请求重写为 https。因此，您不应该同时拥有对给定域的 http 和 https 访问权限。并且任何实现 HSTS (RFC2119) 的人都应该没有真正的面向 http 的站点（即通过 301 将 http 请求重定向到 https 或执行其他操作 [参见第 6.2 节]）。和混合上下文的东西（http到其他非ssl非hsts域资源是一个应该在实现者的基础上（由服务器和浏览器）处理的问题）。也尽量不要模拟它的草稿状态，因为它在 Firefox 和 Google Chrome(ium) 中都实现了[即。约 55% 的浏览器]。