☰

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

tag-icon • tag-icon tls nginx
设置了 Strict-Transport-Security 标头，但 Firefox 和 Chrome 仍在使用 HTTP

我的网站使用 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。

答案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 节），以及一个 Location 标头字段值，该值包含 HTTP 请求的原始有效请求 URI（参见第 9 节（“构建有效请求 URI”））根据需要更改为具有“https”URI 方案，或根据本地策略生成具有“https”URI 方案的 URI。

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

  • 服务器端非安全到安全重定向中的风险 [OWASP-TLSGuide]。
  • 站点部署特性。例如，如果站点包含第三方组件，则在通过非安全传输进行访问时，执行服务器端非安全到安全重定向时可能无法正常运行，但通过安全传输进行统一访问时则正常运行。如果支持 HSTS 的 UA 已将该站点标记为已知 HSTS 主机（无论通过何种方式，例如先前的交互或 UA 配置），则属于后者。HSTS 主机不得在通过非安全传输传输的 HTTP 响应中包含 STS 标头字段。

答案2

这本身并不是一个答案，但是不允许在不安全的连接上设置 Strict-Transport-Security 的原因是，这样做会允许 MITM 攻击者（HSTS 的设计初衷就是针对这一威胁）阻止访问任何实际上不支持 SSL 的站点。

相关内容