增强Nginx的SSL安全性和性能

你的站点启用https了吗?如果启用了,其安全性如何呢?

到站长工具:

http://s.tool.chinaz.com/https/

 

输入网址检测一下,就可以看到报告:

以上这个结果说明基本OK。

 

报告下方有个配置指南,配置指南里有提到两点:

1. 需要配置符合PFS规范的加密套件,推荐配置:

ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4:!DH:!DHE;

2. 需要在服务端TLS协议中启用TLS1.2,推荐配置:

TLSv1 TLSv1.1 TLSv1.2。

我们就这两点对Nginx配置进行调整如下,增加了红色的几行:

    server {
        listen 443 ssl;
        server_name dancen.com www.dancen.com;
        access_log off;
        root /home/site/dancen;
        ssl_certificate /etc/letsencrypt/live/dancen.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/dancen.com/privkey.pem;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4:!DH:!DHE;
		ssl_prefer_server_ciphers on;
		ssl_session_cache shared:SSL:10m;
		ssl_session_timeout 30m;

        error_page 404 /404.html;
        error_page 500 502 503 504 /50x.html;		
    }

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Context:    http, server

这里所做的,就是关闭SSLv2和SSLv3这些古董协议,使用TLSv1 TLSv1.1 TLSv1.2这几个新一点的安全协议,你甚至可以只使用TLSv1.2,TLSv1.3。安全协议这东西,通常越新越安全,但太新的协议,和一些较老的前端可能就会存在兼容问题。

 

ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4:!DH:!DHE;

这里使用了推荐的加密套件,排除了安全性不佳、性能低下的加密算法。加密套件的顺序是非常重要的,因为其决定了优先选择哪个算法。

 

ssl_prefer_server_ciphers on;

设置协商加密算法时,优先使用我们服务端的加密套件,而不是客户端浏览器的加密套件。如果只配置了加密套件,而未设置此项,加密套件的设定就没有意义了。

 

ssl_session_cache shared:SSL:10m;

设置ssl/tls会话缓存的类型和大小。启用https后,会加剧服务器的负担。传统的http使用TCP三次握手建立连接,而SSL和TLS在这个基础上还需要9个握手包,所以这个负担显而易见,可以通过重用Session提高https的性能。

设置存储session参数的缓存的类型和大小。缓存可以是下面任何一种类型:

off

严格禁止使用会话缓存:nginx明确告知客户端会话不可重用。

none

会话缓存是不允许的:nginx告知客户端会话可以重用,但并没有在缓存中存储会话参数。

builtin

在OpenSSL中构建缓存;只能被一个工作进程使用。缓存的大小在会话中指定,如果没有指定大小,默认20480个会话。使用内置缓存会导致内存碎片化。

shared

缓存在所有工作进程之间共享。缓存大小按照字节为单位指定;1MB可以存储4000个会话。每块共享内存都应该起个名字。同一块缓存可以在多个虚拟服务中使用。

 

两种类型的缓存可以同时使用:

ssl_session_cache builtin:1000 shared:SSL:10m;

 

但是,单独使用共享缓存会更有效。这个参数默认是none,和off差不多,停用缓存。我们的设置是shared,因为buildin可能会产生内存碎片,如shared:SSL:10m表示我所有的nginx工作进程共享10m的SSL会话缓存。

 

ssl_session_timeout 30m;

指定客户端可以重用会话参数的时间(超时后不可使用),默认值是5m,即5分钟。

 

其他设置

keepalive_timeout 120s 120s;

Default:    keepalive_timeout 75s;

Context:    http, server, location

另外,设置较长的keepalive_timeout也可以减少请求SSL会话协商的开销,但同时得考虑并发数,因为keepalive_timeout的值过大,会导致存在很多无效的连接。

keepalive_timeout第一个参数:设置keep-alive客户端连接在服务器端保持开启的超时值(默认75s);值为0会禁用keep-alive客户端连接。

keepalive_timeout第二个参数:可选、在响应的header域中设置一个值“Keep-Alive: timeout=time”;通常可以不用设置。

注:keepalive_timeout默认75s,一般情况下也够用,对于一些请求比较大的内部服务器通讯的场景,适当加大为120s或者300s。

 

keepalive_requests 10000;

Default:    keepalive_requests 100;

Context:    http, server, location

keepalive_requests指令用于设置一个keep-alive连接上可以服务的请求的最大数量,当最大请求数量达到时,连接被关闭,默认是100。

大多情况下,当QPS(每秒请求数)不是很高时,默认值100凑合够用。但对一些QPS比较高(比如超过10000QPS,甚至达到30000,50000甚至更高) 的场景,100就显得太低。QPS=10000时,客户端每秒发送10000个请求(通常建立有多个长连接),每个连接只能最多跑100次请求,意味着平均每秒钟就会有100个长连接因此被nginx关闭。同样意味着为了保持QPS,客户端不得不每秒中重新新建100个连接。因此,就会发现有大量的TIME_WAIT的socket连接(即使此时keep alive已经在client和nginx之间生效)。因此对于QPS较高的场景,非常有必要加大这个参数,以避免出现大量连接被生成再抛弃的情况,减少TIME_WAIT。

 

keepalive 300;

保持和后端server的长连接。默认情况下Nginx访问后端都是用的短连接(HTTP1.0),一个请求来了,Nginx新开一个端口和后端建立连接,请求结束连接回收。为了让nginx和后端server(nginx称为upstream)之间保持长连接,典型设置如下:

http {
    upstream service {
        server   127.0.0.1:8080  weight=1 max_fails=2 fail_timeout=30s;
        server   127.0.0.2:8080  weight=1 max_fails=2 fail_timeout=30s;
        keepalive 300; 
    }
server {
        listen 80;
        server_name service.dancen.com;
        location /  {
            proxy_pass http://service;
            proxy_set_header Host  $Host;
            proxy_set_header x-forwarded-for $remote_addr;
            proxy_set_header X-Real-IP $remote_addr;
            add_header Cache-Control no-store;
            add_header Pragma  no-cache;
            proxy_http_version 1.1; 
            proxy_set_header Connection "";
        }
    }
}

设置了长连接,Nginx会接受客户端的请求,处理完成之后Nginx会继续保持和后端的长连接,如果并发请求超过了keepalive指定的最大连接数,Nginx会启动新的连接 来转发请求,新连接在请求完毕后关闭,而且新建立的连接是长连接。keepalive 指定的数值是Nginx每个worker连接后端的最大长连接数,而不是整个Nginx的。而且这里的后端指的是所有的后端,而不是每一个后端。

 

proxy_http_version 1.1;

proxy_set_header Connection "";

HTTP协议中对长连接的支持是从1.1版本之后才有的,因此要使用长连接,就得通过proxy_http_version指令设置为”1.1”。

清理从client过来的http header,因为即使是client和nginx之间是短连接,nginx和upstream之间也是可以开启长连接的。这种情况下必须清理来自client请求中的”Connection” header。

 

TIME_WAIT问题:

Nginx和后端的长连接不够用时Nginx会新建连接来处理新的请求,而我们的配置已经配置了使用HTTP1.1,建立连接后,后端认为是长连接而不会主动关闭连接(一般有个空闲超时),关闭连接由Nginx来做了,所以Nginx会出现大量的TIME_WAIT。

而默认情况下,Nginx用HTTP1.0请求后端,后端处理完成后就主动关闭连接,所以 TIME_WAIT出现在后端。

那么现在有新的问题了,如果开启了长连接,而长连接又大量不够用,此时Nginx存在的 TIME_WAIT可能会大量占用端口,导致端口用尽,如果用尽,后果很严重,因此keepalive要慎重设置。

另外,keepalive_requests设置比较小,高并发下超过此值后Nginx会强制关闭和客户端保持的keepalive长连接,也会导致nginx出现TIME_WAIT。

 

补充内容

client_max_body_size 20m;

Context:    http, server, location

在nginx使用过程中,如果需要上传文件,通常需要设置nginx报文大小限制(默认1m),避免出现413 Request Entity Too Large。

 

TLS1.2

问题:

当在Nginx上设置某个站点的ssl_protocols为TLS1.2时,发现访问站点依然使用的是TLS1.0。

解决办法:

当Nginx上配置了多个站点时,只将某个站点修改成TLS1.2无效,需要将所有的站点统一修改为TLS1.2。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值