为什么 SSL Labs 测试说在通过 HTTP 发送 header 时启用了 HSTS,但在通过 HTTPS 发送时却没有?
Why does SSL Labs test say that HSTS is enabled when the header is sent over HTTP, but not when sent over HTTPS?
我正在尝试在我的服务器上配置 HSTS。我注意到 SSLLabs.com 上的测试会告诉我,如果我通过初始未加密的 HTTP 连接发送 HSTS header,HSTS 已启用。但是,根据 RFC-6797 第 7.2 节,这违反了 HSTS 规范,该规范明确规定您不应通过未加密的连接发送此 header。
另一方面,如果我的服务器仅在执行从 HTTP 到 HTTPS 的 302 重定向后才发送 HSTS header,这正是官方 HSTS 规范所说的你应该做的,那么 SSL Labs 会做不承认我启用了 HSTS。
那么我在这里缺少什么?执行此操作的实际正确方法是什么?
如果你想看看我在说什么,有问题的网站是
nightowlcircusarts.com
您可以通过以下 bash 命令使用 curl 查看未加密的 header:
curl -I http://www.nightowlcircusarts.com/
或将 http 更改为 https 以查看加密的 headers:
curl -I https://www.nightowlcircusarts.com/
目前,我将它配置为仅通过 TLS 发送 header,而不是没有它,正如 HSTS 规范所说的那样。但是您会看到 SSL Labs 测试仍然说我没有启用 HSTS:
https://www.ssllabs.com/ssltest/analyze.html?d=nightowlcircusarts.com
首先,ssllabs 不会扫描未加密连接上的站点 - 仅扫描加密连接 (https) 上的站点。所以它不会告诉你你在http上启用了它。
您的问题是 nightowlcircusarts.com 和 www.nightowlcircusarts.com 是两个不同的站点,您只在后者上设置它但在前者上扫描它:
https://www.ssllabs.com/ssltest/analyze.html?d=nightowlcircusarts.com
https://www.ssllabs.com/ssltest/analyze.html?d=www.nightowlcircusarts.com
现在扫描结果显示,在底部,裸域确实重定向到 www 版本,但 ssllabs 的任务是测试 SSL/TLS 连接(发生在重定向之前),所以它故意这样做不遵循重定向,而是报告 SSL/TLS 连接配置。它希望您单独扫描重定向站点 - 正是针对像这样设置不同的用例!
我想当您“通过初始未加密的 HTTP 连接发送 HSTS header”时,您实际上是在任何地方(包括裸域)设置它通过 https),这就是为什么你认为它在你这样做时“有效”。
在 https-to-https 重定向上设置 HSTS 是允许的(也是预期的!)。事实上,您的具体示例已涵盖 in the RFC in section 11.4.1.
顺便说一句,将 HSTS 添加到裸域是最佳做法,但请确保您的整个域仅通过 https 提供服务。如果您有一个子站点(例如 blog.example.com)或者也将其用于尚未保护的非 public 站点(例如 intranet.example.com),那么这可能会导致问题。在这种情况下,您可以将 HSTS 添加到裸域但不使用 includeSubdomain 选项 - 尽管这不会为您提供 HSTS 的全面保护。
最后,如果检查网站的各种安全性 Headers 而不是 SSL/TLS 配置,那么 https://securityheaders.io 是一个很棒的网站,而且 运行比 ssllabs 所做的整套 SSL/TLS 测试还要多:
https://securityheaders.io/?q=https%3A%2F%2Fnightowlcircusarts.com
https://securityheaders.io/?q=https%3A%2F%2Fwww.nightowlcircusarts.com
请注意,这两个站点会检查不同的内容,因此我们不能替代另一个站点(两者都是忠实粉丝!),但两者都显示了一些设置(HSTS 和 HPKP)。虽然在这个问题上要非常小心 HPKP(我不是粉丝,也不认为它应该被广泛使用)。
我正在尝试在我的服务器上配置 HSTS。我注意到 SSLLabs.com 上的测试会告诉我,如果我通过初始未加密的 HTTP 连接发送 HSTS header,HSTS 已启用。但是,根据 RFC-6797 第 7.2 节,这违反了 HSTS 规范,该规范明确规定您不应通过未加密的连接发送此 header。
另一方面,如果我的服务器仅在执行从 HTTP 到 HTTPS 的 302 重定向后才发送 HSTS header,这正是官方 HSTS 规范所说的你应该做的,那么 SSL Labs 会做不承认我启用了 HSTS。
那么我在这里缺少什么?执行此操作的实际正确方法是什么?
如果你想看看我在说什么,有问题的网站是 nightowlcircusarts.com
您可以通过以下 bash 命令使用 curl 查看未加密的 header:
curl -I http://www.nightowlcircusarts.com/
或将 http 更改为 https 以查看加密的 headers:
curl -I https://www.nightowlcircusarts.com/
目前,我将它配置为仅通过 TLS 发送 header,而不是没有它,正如 HSTS 规范所说的那样。但是您会看到 SSL Labs 测试仍然说我没有启用 HSTS: https://www.ssllabs.com/ssltest/analyze.html?d=nightowlcircusarts.com
首先,ssllabs 不会扫描未加密连接上的站点 - 仅扫描加密连接 (https) 上的站点。所以它不会告诉你你在http上启用了它。
您的问题是 nightowlcircusarts.com 和 www.nightowlcircusarts.com 是两个不同的站点,您只在后者上设置它但在前者上扫描它:
https://www.ssllabs.com/ssltest/analyze.html?d=nightowlcircusarts.com
https://www.ssllabs.com/ssltest/analyze.html?d=www.nightowlcircusarts.com
现在扫描结果显示,在底部,裸域确实重定向到 www 版本,但 ssllabs 的任务是测试 SSL/TLS 连接(发生在重定向之前),所以它故意这样做不遵循重定向,而是报告 SSL/TLS 连接配置。它希望您单独扫描重定向站点 - 正是针对像这样设置不同的用例!
我想当您“通过初始未加密的 HTTP 连接发送 HSTS header”时,您实际上是在任何地方(包括裸域)设置它通过 https),这就是为什么你认为它在你这样做时“有效”。
在 https-to-https 重定向上设置 HSTS 是允许的(也是预期的!)。事实上,您的具体示例已涵盖 in the RFC in section 11.4.1.
顺便说一句,将 HSTS 添加到裸域是最佳做法,但请确保您的整个域仅通过 https 提供服务。如果您有一个子站点(例如 blog.example.com)或者也将其用于尚未保护的非 public 站点(例如 intranet.example.com),那么这可能会导致问题。在这种情况下,您可以将 HSTS 添加到裸域但不使用 includeSubdomain 选项 - 尽管这不会为您提供 HSTS 的全面保护。
最后,如果检查网站的各种安全性 Headers 而不是 SSL/TLS 配置,那么 https://securityheaders.io 是一个很棒的网站,而且 运行比 ssllabs 所做的整套 SSL/TLS 测试还要多:
https://securityheaders.io/?q=https%3A%2F%2Fnightowlcircusarts.com
https://securityheaders.io/?q=https%3A%2F%2Fwww.nightowlcircusarts.com
请注意,这两个站点会检查不同的内容,因此我们不能替代另一个站点(两者都是忠实粉丝!),但两者都显示了一些设置(HSTS 和 HPKP)。虽然在这个问题上要非常小心 HPKP(我不是粉丝,也不认为它应该被广泛使用)。