Nginx之SSL配置项解析

发表于 | 分类于 | 次阅读

常见参数

  • ssl_certificate 证书其实是个公钥，它会被发送到连接服务器的每个客户端
  • ssl_certificate_key 私钥是用来解密的，所以它的权限要得到保护但nginx的主进程能够读取。
  • ssl_session_timeout 客户端可以重用会话缓存中ssl参数的过期时间，内网系统默认5分钟太短了，可以设成30m即30分钟甚至4h。
  • ssl_session_cache shared:SSL:10m; : 设置ssl/tls会话缓存的类型和大小。
    • shared 所有工作进程之间共享缓存。缓存大小以字节为单位指定；一兆字节可以存储大约4000个session。每个共享缓存都应该有一个任意名称。具有相同名称的缓存可以用于多个虚拟服务器。
    • off 严禁使用session缓存：nginx明确告诉客户端session可能不会被重用。
    • none session缓存的使用被禁止：nginx告诉客户端session可能会被重用，但实际上并不会将session参数存储在缓存中。
    • builtin 在OpenSSL中构建的缓存；仅由一个工作进程使用。缓存大小在session中指定。如果没有给出大小，则等于20480个会话。使用内置高速缓存可能导致内存碎片。
    • 注意： builtin和shared可以同时使用，但是Nginx官方说只使用shared缓存，而不使用built-in缓存的性能应该会更高。配置案例：
      ssl_session_cache builtin:1000 shared:SSL:10m;
  • 设置较长的keepalive_timeout也可以减少请求ssl会话协商的开销，但同时得考虑线程的并发数了。
  • ssl_protocols指令用于启动特定的加密协议，nginx在1.1.13和1.0.12版本后默认是ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2，TLSv1.1与TLSv1.2要确保OpenSSL >= 1.0.1 ，SSLv3 现在还有很多地方在用但有不少被攻击的漏洞。
  • ssl_ciphers选择加密套件，不同的浏览器所支持的套件（和顺序）可能会不同。这里指定的是OpenSSL库能够识别的写法，你可以通过 openssl -v cipher ‘RC4:HIGH:!aNULL:!MD5’（后面是你所指定的套件加密算法） 来看所支持算法。
    • 加密套件 之间用冒号分隔，加密套件 前有感叹号的表示必须废弃。
  • ssl_prefer_server_ciphers on设置协商加密算法时，优先使用我们服务端的加密套件，而不是客户端浏览器的加密套件。

HSTS（HTTP Strict Transport Security，严格传输安全）

  • HSTS 简单说就是在一定时间内强制客户端使用 HTTPS 访问页面。原理如下：

    在服务器响应头中添加 Strict-Transport-Security，可以设置 max-age
    用户访问时，服务器种下这个头
    下次如果使用 HTTP 访问，只要 max-age 未过期，客户端会进行内部跳转，可以看到 307 Redirect Internel 的响应码（注意是客户端浏览器相应的，这里给服务器省下了一次 302 跳转）
    变成 HTTPS 访问源服务器

  • 这个过程有效避免了中间人对 80 端口的劫持。但是这里存在一个问题：如果用户在劫持状态，并且没有访问过源服务器，那么源服务器是没有办法给客户端种下 Strict-Transport-Security 响应头的（都被中间人挡下来了）。如何解决？

  • 需要注意的是，只有启用 preload（预加载） 之后才是严格意义上安全的 HTTPS。否则都可能在最薄弱环节被攻破。比如：

    • 允许 SSL 连接但不强制从 HTTP 跳转到 HTTPS，用户访问 HTTP 被劫持
    • 部署了 HSTS，但用户第一次访问是 HTTP 的，Strict-Transport-Security 的响应头没有作用的机会，还是被劫持。

OSCP Stapling

  • 当我们通过HTTPS访问网站的时候，客户端会通过证书颁发机构的证书吊销列表（CRL）或者数字证书在线状态协议(OCSP)记录验证网站服务器的证书是否有效。前一种验证方式是最低效的，CA会不断向CRL文件添加证书吊销记录，CRL文件就会变得越来越大，客户端在验证前就需要耗费越来越长的时间来下载CRL文件。

  • 相比 CRL 验证方式，OCSP 就更加高效，OCSP 每次只查询并获取一条记录。然而这些默认查询 OCSP 的客户端在获得查询结果的响应前势必会一直阻塞后续的事件，在网络情况堪忧的情况下（尤其是大陆地区）会造成较长时间的页面空白。并且一旦有黑客或者组织对CA的OCSP发动DDos攻击（分布式拒绝攻击），客户端便无法从 OCSP 服务器获取查询结果并完成证书验证, 客户端就可能会提示网站不受信任。

  • 而 OCSP Stapling ，顾名思义，是将查询 OCSP 接口的工作交给服务器来做，服务器除了可以直接查询 OCSP 信息，还可以仅进行少数次查询并将响应缓存起来。当有客户端向服务器发起 TLS 握手请求时，服务器将证书的 OCSP 信息随证书链一同发送给客户端，从而避免了客户端验证会产生的阻塞问题。由于 OCSP 响应是无法伪造的，因此这一过程也不会产生额外的安全问题。

  • 值得注意的是：Nginx会在客户端的HELLO握手信息中返回OCSP记录，并且只有当客户端对Nginx发出OCSP信息请求的情况下，Nginx才会发送缓存的OCSP 权威记录到客户端。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
ssl_stapling on;
# OCSP Stapling 开启。OCSP是用于在线查询证书吊销情况的服务，使用OCSP Stapling能将证书有效状态的信息缓存到服务器，提高 TLS 握手速度
 
ssl_stapling_verify on; 
# OCSP Stapling 验证开启
 
ssl_trusted_certificate /etc/nginx/cert/trustchain.crt; 
# OCSP Stapling 的证书位置（完整的证书链）
 
resolver 233.5.5.5 233.6.6.6 valid=300s; 
# 用于查询 OCSP 服务器的DNS
 
resolver_timeout 5s;
#查询域名超时时间

缓存连接凭据

  • 缓存 SSL 连接凭据可以避免频繁握手带来的速度降低和性能损耗。
  • TLS 协议有两类会话缓存机制：会话标识 session ID 与会话记录 session ticket。session ID 由服务器端支持，协议中的标准字段，因此基本所有服务器都支持，服务器端保存会话ID以及协商的通信信息，Nginx 中1M 内存约可以保存4000个 session ID 机器相关信息，占用服务器资源较多；而 session ticket 属于一个 TLS 扩展字段，需要服务器和客户端都支持。
  • 二者对比，主要是保存协商信息的位置与方式不同，类似与 HTTP 中的 session 与 cookie。都存在的情况下，Nginx 优先使用 session_ticket。
1
2
3
4
5
6
7
8
9
ssl_session_cache shared:SSL:20m; 
# SSL session 缓存区大小
# 这条语句加在server段里话，在SSL Lab的测试中识别不出来，因为它假设客户端不支持SNI协议，但实际上是可以加在server段的
 
ssl_session_tickets on;
# 开启浏览器的 Session Ticket 缓存
 
ssl_session_timeout 60m; 
# 过期时间，分钟

301 跳转

跳转到https

1
2
3
4
server { 
    listen 80; 
    return 301 https://$host$request_uri; 
}

HTTP/2

尽管 HTTP/2 协议本身并不要求一定开启 SSL，但大多数主流浏览器要求一定要启用 SSL 才能使用 HTTP/2。要使用 HTTP/2，把 listen directive 改成 listen 443 ssl http2 即可。HTTP/2 是 SPDY 的演进版本，性能上相比 HTTP 1.1 最主要的是增加了多路复用 multiplexing、header 压缩和二进制格式。

1
2
3
4
server {
    listen 443 ssl http2;
    ...
}

双向认证配置proxy_ssl_verify_depth

The depth actually is the maximum number of intermediate certificate issuers, i.e. the number of CA certificates which are max allowed to be followed while verifying the client certificate. A depth of 0 means that self-signed client certificates are accepted only, the default depth of 1 means the client certificate can be self-signed or has to be signed by a CA which is directly known to the server (i.e. the CA’s certificate is under SSLCACertificatePath), etc.

当待验证的客户端证书是由intermediate-CA签发，而非有root-CA签发时，需要在proxy_ssl_trusted_certificate中配置intermediate-CA和root-CA组成的证书链文件
也就是说，直接尝试使用中级 CA 来验证客户端是无法通过的，openssl 会自动的去找中级 CA 的签发者一层层验证上去，直到找到根。

因此，在实际使用的时候，需要注意一下两点：

  • CA 文件中必须同时存在 中级 CA 和 根 CA，必须构成完整证书链，不能少任何一个；
  • 默认的验证深度 SslVerifyDepth ssl_verify_depth 是 1，也就是说只要是中级 CA 签发的客户端证书一律无法通过认证，需要增大该值。
--------------------本文结束，感谢您的阅读--------------------