nginx ssl 和 hsts 设置

nginx ssl and hsts setting

我想将 http 重定向到 https 并使用 hsts

https://hstspreload.org/
(测试失败)错误:无 HSTS header 响应错误:响应中没有 HSTS header。

如何同时设置重定向和hsts?

P.S 我已经使用 aws ssl 证书和 elb 设置了负载平衡。

/etc/nginx/conf.d/default.conf

server {
listen 80 default_server;
listen [::]:80 default_server;
server_name My_domain;

if ($http_x_forwarded_proto = "http") {
    return 301 https://$server_name$request_uri;
}

location / {
    root /usr/share/nginx/html;
    try_files $uri $uri/ /index.html;
}

location /api/ {
    proxy_pass              http://localhost:8080;
}

server {
    listen 443 ssl;
    server_name My_domain;

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

关于您的设置,您没有提供足够的信息,但我可以猜测发生了什么。

我猜你是在你的 ELB 上卸载你的 SSL 并向 Nginx 发送明文 HTTP 消息,HTTP_X_FORWARDED_PROTO header 设置为原始方案。

因此,如果用户转到 https://www.example.com then it offloads the SSL/TLS and directs traffic to http://www.example.com,并且 HTTP_X_FORWARDED_PROTO 设置为 "https"。在这种情况下,没有重定向(因为用户已经在使用 HTTPS),也没有 HSTS header(因为用户没有使用 HTTPS 到 nginx,你只在 443 服务器配置中设置 header)。您应该将其添加到您的端口 80 服务器,以便在这种情况下也为 HSTS header 提供服务:

if ($http_x_forwarded_proto = "https") {
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

从技术上讲,您不应该通过 HTTP 而只能通过 HTTPS 提供 HSTS header,因此最好在负载平衡级别设置,但我认为 $http_x_forwarded_proto header这个可以。

但是,如果我的猜测是正确的,那么这就证明你没有正确使用 HSTS,所以我不在这里添加一些警告是我的疏忽。

HSTS 并非没有风险。

HSTS 很好地解决了当前 Web 默认不是 HTTPS 的事实,这会导致各种安全风险。然而,如果您仍然需要使用 HTTP,这并非没有风险。例如,如果您有一些子域尚未转换为 HTTPS(例如 blog.example.com),或者如果您将相同的域用于尚未转换的内部站点(例如 intranet.example.com)或开发站点( dev.example.com)。最后一个也可能是一个问题,因为 HSTS 不允许您跳过过去的 HTTPS 错误(例如,如果您的开发域使用 self-signed 证书)。这并不是说你不应该使用 HSTS - 但你应该在给自己(和你的组织)带来很多痛苦之前充分理解它并测试它。

出于这个原因,建议从小的 max-age 开始,而不是全年 (max-age= 31536000) 并逐渐增加。而不是全力以赴并破坏事物。这样,如果您发现需要转换的网站,您不会将其锁定一年或直到您转换为 HTTPS。

对于预加载尤其如此,您将 header 烘焙到浏览器代码库中,因此它甚至在您访问该站点之前就从一开始就打开了。您基本上无法撤消此操作(Chrome 至少需要 3 个月才能将其删除,而其他浏览器则没有给出时间表)。所以,因为它基本上是不可逆的,所以在你完全测试它之前,你永远不应该进行预加载,看起来你还没有。 Chrome has an issue tracking all the screw ups that sites have done where they have requested preload and then broken things. I've blog about this danger, as have others. Additionally preload has some other requirements (you must add the preload attribute to your header and you must serve this header over your base domain (https://example.com) 以及) 你似乎没有开会。

基域问题尤其会导致问题,例如,如果您从不正常访问该域,那么测试 https://www.example.com looks fine and http://intranet.example.com still works (as you've never set the HSTS header at the base domain so it can continue to be sent over HTTP) and then you preload and boom - http://intranet.example.com stops working. The easiest way to test this is to add a resource from this base domain to your www site (e.g. https://example.com/pixel.png) 将强制访问基域的任何人使用 HSTS header您的网站。

HSTS 很棒。每个网站都应该使用它,每个网站都应该只使用 HTTPS——但在他们这样做之前,这并非没有风险。确保在部署时了解它。慢慢来,建立一个大 max-age。然后才进行预加载。

要在 https://hstspreload.org/ 上成功通过测试,请不要忘记将预加载指令添加到 header 配置中:

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

这不是规范的一部分,但 Google 建议 include it in the response