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 請求，有效杜絕不安全的請求訪問。