Nginx基础知识点汇总3

问题
客户端与 NGINX 服务器之间的请求数据需要加密处理。
解决方案
启用 ngx_http_ssl_module 或 ngx_stream_ssl_module 其中之一的 NGINX SSL
模块对数据进行加密：

http {
// All directives used below are also valid in stream
	server {
		listen 8433 ssl;
		ssl_protocols TLSv1.2;
		ssl_ciphers HIGH:!aNULL:!MD5;
		ssl_certificate /usr/local/nginx/conf/cert.pem;
		ssl_certificate_key /usr/local/nginx/conf/cert.key;
		ssl_session_cache shared:SSL:10m;
		ssl_session_timeout 10m;
	}
}

实例在 server 块级指令中设置监听启用 ssl 加密的 8843 端口。使用的 ssl 协议
为 TLS1.2 版本。服务器有访问 SSL 证书及密钥目录的权限。另外，服务器和客户端
交互采用最高强度加密数据。ssl_sesson_cache 和 ssl_session_timeout 指令用于
设置会话存储内存空间和时间，除这两个指令外，还有一些与会员有关的指令，可以
用于提升性能和安全性。However,specifying one without the default will turn
off that default, built-in session cache.

结论
安全传输层是加密传输数据的常用手段。在写作本书时，传输层安全协议(TSL)是
安全套接字层协议(SSL)的默认协议，因为，现在认为 1.0 到 3.0 版本的 SSL 协
议都是不安全的。尽管安全协议的名称有所不同，但无论 TSL 协议还是 SSL 协议
它们的最终目的都是构建一个安全的套接层。NGINX 服务器让你能在服务与客户端
之间构建加密的数据传输，保证业务与用户数据安全。使用签名证书时，需要将证
书与证书颁发机构链连接起来。证书和颁发机构通信时时，你的证书应该在文件链
中。如果您的证书颁发机构在链中提供了许多文件，它也能够提供它们分层的顺序。
SSL 会话缓存性能通过不带版本信息和数据加密方式的 SSL / TLS 协议实现。

问题
需要在 NGINX 与 upstream 代理服务器之间依据具体规则构建安全通信。
解决方案
使用 http 模块的 ssl 指令构建具体的 SSL 通信规则:

location / {
	proxy_pass https://upstream.example.com;
	proxy_ssl_verify on;
	proxy_ssl_verify_depth 2;
	proxy_ssl_protocols TLSv1.2;
}

示例中配置了 NGINX 与代理服务器之间通信的 SSL 规则。首先启用安全传输校验功
能，并将 NGINX 与代理服务器之间的证书校验深度设置为 2 层。proxy_ssl_protocols
指令用于设置使用 TSL 1.2 版本协议，它的默认值是不会校验证书，并可以使用所有
版本 TLS 协议。

结论
HTTP proxy 模块的指令繁多，如果需要启用安全传输功能，至少也需要开启校验功能。
此外，我们还可以对 proxy_pass 指令设置协议，来实现 HTTPS 传输。不过，这种方
式不会对被代理服务器的证书进行校验。其它的指令，如 proxy_ssl_certificate 和proxy_ssl_certificate_key 指令，用于配置被代理服务器待校验证书目录。另外，还有 proxy_ssl_crl 和 无效证书列表功能，用于列出无需认证的证书。这些 proxy 模块的 SSL 指令能够助你构建安全的内部服务通信和互联网通信。

问题
需要将用户请求从 HTTP 协议重定向至 HTTPS 协议。
解决方案
通过使用 rewrite 重写将所有 HTTP 请求重定向至 HTTPS:

server {
	listen 80 default_server;
	listen [::]:80 default_server;
	server_name _;
	return 301 https://$host$request_uri;
}

server 块级指令配置了用于监听所有 IPv4 和 IPv6 地址的 80 端口，return 指令将请求及请求 URI 重定向至相同域名的 HTTPS 服务器并响应 301 状态码给客户端。

结论
在必要的场景下将 HTTP 请求重定向至 HTTPS 请求对系统安全来说很重要。有时，我们并不需要将将所有的用户请求都重定向至 HTTPS 服务器，而仅需将包含用户敏感数据的请求重定向至 HTTPS 服务即可，比如用户登录服务。

问题
需要告知浏览器不要使用 HTTP 发送请求
解决方案
通过设置 Strict-Transport-Security 响应不信息，启用 HTTP Strict Transport Security 策略，告知浏览器不支持 HTTP 请求:

add_header Strict-Transport-Security max-age=31536000;

这里，我们将 Strict-Transport-Security 消息头有效期设置为 1 年，其作用是，当用户发起一个 HTTP 请求时，浏览器在内部做一个重定向，将所有请求直接通过 HTTPS 协议访问。

结论
这是因为即使我们在服务器内部启用了 HTTPS 重定向功能，但浏览器端依然是 HTTP
请求，这可能会被中间人攻击，导致用户敏感数据泄露。这时候 HTTPS 重定向功能无
法保证数据的安全性。当使用 Strict-Transport-Security 头时，浏览器将不会发送未被加密的 HTTP 请求，取而代之的是 HTTPS 请求，有效杜绝不安全的请求访问。