Strict-Transport-Security 标头设置，但 Firefox 和 Chrome 仍在使用 HTTP

Question

我的网站使用来自 CloudFlare 的 Universal SSL，我希望浏览器自动重定向到 HTTPS。但是，由于并非所有浏览器都支持 cloudflare 使用的 SSL 类型，因此我不想直接强制使用 SSL。所以HSTS似乎是一个不错的选择。但是，当我在浏览器中对其进行测试时，它似乎并没有像我预期的那样工作。

在我的站点配置文件中，我有这一行：

server {
    ...
    listen 443 ssl;
    add_header Strict-Transport-Security max-age=63072000;
    ...
}

它显示在响应标头中：

Strict-Transport-Security: max-age=63072000

但是，Windows 10 和 OS X 10.10.3 上的 Firefox 35 和 Chrome 41 仍将通过 HTTP 导航该站点，而不会重定向到 HTTPS。

我正在使用在 CentOS 7 上运行的 NGINX 版本 1.7.3。

Answer 1

STS 响应头仅对安全方案有效。客户端必须至少访问 https 页面一次才能在 HSTS 缓存中获取 STS 条目。

规范建议服务器应该从 HTTP 重定向到 https，但这并不总是可行的。因此，您可以尝试在后端嗅探不受支持的 User-Agent，并且仅在 UA 未列入黑名单时才发出重定向。

有关更多背景信息，请参阅RFC 6797 的第 7.2 节：

7.2. HTTP 请求类型
如果 HSTS 主机通过非安全传输接收 HTTP 请求消息，它应该发送包含指示永久重定向的状态代码的 HTTP 响应消息，例如状态代码 301（[RFC2616] 的第 10.3.2 节） ，以及包含 HTTP 请求的原始有效请求 URI（参见第 9 节（“构造有效请求 URI”））的位置标头字段值，根据需要进行更改以具有“https”的 URI 方案，或根据本地生成的 URI URI 方案为“https”的策略。

注意：上述行为是“应该”而不是“必须”，因为：

• 服务器端非安全到安全重定向的风险 [OWASP-TLSGuide]。
• 站点部署特性。例如，在通过非安全传输访问的情况下执行服务器端非安全到安全重定向时，包含第三方组件的站点可能无法正确运行，但在通过安全传输统一访问时却可以正确运行。后者是给定具有 HSTS 能力的 UA 的情况，该 UA 已经将该站点标记为已知 HSTS 主机（通过任何方式，例如，先前的交互或 UA 配置）。HSTS 主机不得在通过非安全传输传输的 HTTP 响应中包含 STS 头字段。