【问题标题】:HSTS Preload differing resultsHSTS 预加载不同的结果
【发布时间】:2021-06-24 10:06:06
【问题描述】:

在我的一个站点上,我有 Header set Strict-Transport-Security "max-age=31536000" env=HTTPS,这足以预加载 HSTS,但我的 .htaccess 文件中完全相同的 sn-p 不允许在另一个站点上预加载。我已经使用Header set Strict-Transport-Security: "max-age=31536000; includeSubDomains; preload" env=HTTPS 解决了这个问题,但我想知道为什么较短的版本可以工作并预加载第一个站点而不是第二个站点?

任何见解将不胜感激。

【问题讨论】:

  • AFAIK 你总是需要includeSubDomains;preload 属性来考虑预加载提交工具。您确定没有在其他站点中设置它们吗?也许在不同的配置?
  • 两者的配置相同,这就是我感到困惑的原因。

标签: apache .htaccess ssl preload hsts


【解决方案1】:

为什么较短的版本有效

短版不可能“工作”。实施 HSTS 就足够了,但没有被HSTS preload list 接受。

您的配置中的其他内容一定已经发送了完整的标头。

确认实际情况的唯一方法是记录在请求中发送的 HTTP 请求/响应标头,而不是通过 (.htaccess?) 配置文件中的指令。

即使您发布的指令本身也不一定足够。您必须有设置 HTTPS 环境变量的东西(这与 HTTPS server 变量不同)。如果您有从 www 到非 www 的规范重定向(反之亦然),那么您缺少 always 参数来设置 301 重定向上的标头(仅限 HTTPS) - 这也是“预加载列表”的要求.

在服务器配置中实现 HSTS“预加载”要容易得多且不易出错。如果您只能访问.htaccess,那么我会犹豫是否要提交“预加载列表”。

另见my answer CodeReview SE 上的以下相关问题:

【讨论】:

  • 两者的配置相同,这就是我感到困惑的原因。我赞赏您在回复中提供的信息。我自己也将对此进行更多研究,以了解当他们都以相同方式使用重定向和 .htaccess 时有什么区别。
猜你喜欢
  • 1970-01-01
  • 2021-09-09
  • 1970-01-01
  • 2021-07-31
  • 2017-11-28
  • 1970-01-01
  • 2012-05-30
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多