☰

nginx 中带有规范 URL 重定向的 HSTS

tag-icon • tag-icon nginx hsts
nginx 中带有规范 URL 重定向的 HSTS

我使用的是 nginx 配置摘自这篇文章实施重定向http://(www.)example.com->https://example.com：

server {
    server_name www.example.com example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    <possibly other ssl directives if you have a separate cert and key for www>
    server_name www.example.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    ssl_certificate /path/to/server.cert;
    ssl_certificate_key /path/to/server.key;
    server_name example.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    <locations for processing requests>
}

我想将 HSTS 添加到其中，因此我正在关注nginx 文档，相当于添加

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

到两个 SSL 服务器块（如上所述）。

TLDR：第二个服务器块中的 STS 标头是否必要？

然而，我正在阅读一些有关这个主题的文章，尤其是这篇博文似乎认为：

...如果您的规范 URL 是 www.example.com，则 includeSubDomains 令牌将不会保护 example.com，因为这不是 www.example.com 的子域。解决方案是从 www.example.com 向 上的未缓存资源（https:// example.com例如 1px 图像）发出请求，并确保 https:// example.com 设置 HSTS 标头。

我想这是正确的，因为如果你直接去规范https://www.example.com那么它只会保护http://*.www.example.com.

https://example.com但是，如果您的规范 URL 是并且您使用 ，则这似乎不是问题includeSubDomains。我在 Chrome 上进行了测试，它执行了以下操作http://www.example.com(307) -> https://www.example.com(301) -> https://example.com。

那么Strict-Transport-Security第二个listen 443 ssl www.example.com块中的标头是否必要？ 无论如何，直接请求都会是 SSL，并且它会在从第三个服务器块重定向时https://www.example.com拾取 STS标头，以在将来提供保护。includeSubDomainshttp://www.example.com

答案1

是的，最好在两个server块中都有 STS 标头，原因如您在问题中所写。

从另一个角度来看，在服务器中指定标头也没有什么坏处example.com。

相关内容