如何一步步構建安全的 HTTPS 站點
通常一個 web 站點開啟 HTTPS ，以 nginx 為例，我們可以這樣進行配置：
server {
listen 443 ssl http2;
server_name www.example.com;
index index.html index.htm;
root /www/www;
ssl on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_certificate /usr/local/nginx/ssl/example.com.rsa.cer;
ssl_certificate_key /usr/local/nginx/ssl/example.com.rsa.key;
ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5;;
}
上述 nginx 配置中包含了配置監聽埠、開啟ssl、配置證書、以及支援的加密演算法。一般來說使用者訪問域名不可能直接在瀏覽器的位址列中輸入 https://www.example.com 來進行訪問，而是輸入域名，預設情況下是通過 HTTP 協議來進行訪問的，即 http://www.example.com，因此，在nginx 的配置中我們還需要定義一個server 段來處理 HTTP 的訪問。
server {
listen 80 default_server;
server_name _ www.example.com;
location / {
return 302 https://$host$request_uri;
}
}
上述配置中監聽了 80埠，並且定義了一個 location，將 HTTP 請求 302 跳轉到 HTTPS 的Host 去。這樣就實現了使用者不管怎麼訪問都可以跳轉到 HTTPS 。
但是問題來了，這樣的配置其實是有缺陷的，如果使用者端從瀏覽器手動輸入的是 HTTP 地址，或者從其它地方點選了網站的 HTTP 連結，那麼瀏覽器會依賴於服務端 301/302 跳轉才能使用 HTTPS 服務。而第一次的 HTTP 請求就有可能被劫持，因為中間的資料傳輸是明文的，就有可能會導致請求無法到達伺服器，從而構成 HTTPS 降級劫持。
要解決降級劫持，我們可以使用HSTS。
什麼是 HSTS?
HSTS(HTTP Strict Transport Security，HTTP 嚴格傳輸安全)，是一套由網際網路工程任務組釋出的網際網路安全策略機制。網站可以通過配置 HSTS，來強制瀏覽器使用 HTTPS 與網站通訊，保障網站更加安全。
HSTS的作用是強制客戶端(如瀏覽器)使用HTTPS與伺服器建立連線。伺服器開啟HSTS的方法是，當客戶端通過HTTPS發出請求時，在伺服器返回的超文字傳輸協議響應頭中包含 `Strict-Transport-Security` 欄位。非加密傳輸時設定的`HSTS`欄位無效。
比如，`https://example.com/`的響應頭含有`Strict-Transport-Security: max-age=31536000; includeSubDomains`。這意味著兩點：
在接下來的一年(即31536000秒)中，瀏覽器只要向`example.com`或其子域名傳送HTTP請求時，必須採用`HTTPS`來發起連線。比如，使用者點選超連結或在位址列輸入 `http://www.example.com/` ，瀏覽器應當自動將 http 轉寫成 `https`，然後直接向 `https://www.example.com/` 傳送請求。
在接下來的一年中，如果 `example.com` 伺服器傳送的`TLS`證書無效，使用者不能忽略瀏覽器警告繼續訪問網站。
如何進行配置?
以 nginx 為例，我們在對應域名的 vhost 中增加響應頭：
server {
....
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
...
}
引數解釋：
- max-age，單位是秒，用來告訴瀏覽器在指定時間內，這個網站必須通過 HTTPS 協議來訪問。也就是對於這個網站的 HTTP 地址，瀏覽器需要先在本地替換為 HTTPS 之後再發送請求。
- includeSubDomains，可選引數，如果指定這個引數，表明這個網站所有子域名也必須通過 HTTPS 協議來訪問。
- preload，可選引數，HSTS 這個響應頭只能用於 HTTPS 響應;網站必須使用預設的 443 埠;必須使用域名，不能是 IP。而且啟用 HSTS 之後，一旦網站證書錯誤，使用者無法選擇忽略。
瀏覽器請求後響應頭中會顯示：
strict-transport-security:max-age=31536000
如圖所示：
HSTS 可以很好地解決 HTTPS 降級攻擊，但是對於 HSTS 生效前的首次 HTTP 請求，依然無法避免被劫持。瀏覽器廠商們為了解決這個問題，提出了 HSTS Preload List 方案：內建一份可以定期更新的列表，對於列表中的域名，即使使用者之前沒有訪問過，也會使用 HTTPS 協議。
目前這個 Preload List 由 Google Chrome 維護，Chrome、Firefox、Safari、IE 11 和 Microsoft Edge 都在使用。如果要想把自己的域名加進這個列表，首先需要滿足以下條件：
- 擁有合法的證書(如果使用 SHA-1 證書，過期時間必須早於 2016 年);
- 將所有 HTTP 流量重定向到 HTTPS;
- 確保所有子域名都啟用了 HTTPS;
- 輸出 HSTS 響應頭：
- max-age 不能低於 18 周(10886400 秒);
- 必須指定 includeSubdomains 引數;
- 必須指定 preload 引數;
但是，即便滿足了上述所有條件，也不一定能進入 HSTS Preload List，更多資訊可以看這裡(https://hstspreload.org/)。通過 Chrome 的 chrome://net-internals/#hsts 工具，可以查詢某個網站是否在 Preload List 之中，還可以手動把某個域名加到本機 Preload List。
對於 HSTS 以及 HSTS Preload List，我的建議是隻要你不能確保永遠提供 HTTPS 服務，就不要啟用。因為一旦 HSTS 生效，你再想把網站重定向為 HTTP，之前的老使用者會被無限重定向，唯一的辦法是換新域名。
如果確定要開啟，點選https://hstspreload.org，輸入你的域名，勾選協議，提交即可。
確認後，你就可以將你的域名提交給 HSTS 預載入列表了：
提交成功後會給你返回成功的資訊，不過你要保證你的配置比如是一直開啟了，否則也會從列表中刪除。
再次訪問，檢視瀏覽器響應頭：
此外，我們要做到讓HTTPS 網站更安全更快速，還應當做到以下幾點：
第一，金鑰要足夠的複雜，以rsa 金鑰對為例，最好超過2048位;
第二，ssl_ciphers 的合理配置，儘量拋棄那些已經被證明不安全的加密演算法，使用較新的被證明無安全威脅的演算法，例如可以這樣配置：
ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+ECDSA+AES128:EECDH+aRSA+AES128:RSA+AES128:EECDH+ECDSA+AES256:EECDH+aRSA+AES256:RSA+AES256:EECDH+ECDSA+3DES:EECDH+aRSA+3DES:RSA+3DES:TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:TLS-AES-128-GCM-SHA256:EECDH+CHACHA20:EECDH+AESGCM:EECDH+AES:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!KRB5:!aECDH:!EDH+3DES;
第三，避免使用已經被證明不安全的加密協議，例如 SSLV2和SSLV3 ，而使用 TLSv1.2 TLSv1.3;
ssl_protocols TLSv1.2 TLSv1.3;
一般來說較新的協議都是針對上一個版本進行了很多的優化，比如TLS1.2和TLS1.3協議，可以看下這2個協議的加密過程，首先，我們看下 TLS1.2的加密過程：
以 ECDHE 金鑰交換演算法為例，TLS1.2協議完整的SSL握手過程如下：
- 第一步，首先客戶端傳送ClientHello訊息，該訊息中主要包括客戶端支援的協議版本、加密套件列表及握手過程需要用到的ECC擴充套件資訊;
- 第二步，服務端回覆ServerHello，包含選定的加密套件和ECC擴充套件;傳送證書給客戶端;選用客戶端提供的引數生成ECDH臨時公鑰，同時回覆ServerKeyExchange訊息;
- 第三步，客戶端接收ServerKeyExchange後，使用證書公鑰進行簽名驗證，獲取伺服器端的ECDH臨時公鑰，生成會話所需要的共享金鑰;生成ECDH臨時公鑰和ClientKeyExchange訊息傳送給服務端;
- 第四步，伺服器處理ClientKeyExchange訊息，獲取客戶端ECDH臨時公鑰;伺服器生成會話所需要的共享金鑰;傳送金鑰協商完成訊息給客戶端;
- 第五步，雙方使用生成的共享金鑰對訊息加密傳輸，保證訊息安全。
可以看到，TLS1.2 協議中需要加密套件協商、金鑰資訊交換、ChangeCipherSpec 協議通告等過程，需要消耗 2-RTT 的握手時間，這也是造成 HTTPS 協議慢的一個重要原因之一。
通過抓包分析，我們可以看到他的整個加密過程：
接下來，我們看下 TLS 1.3 的的互動過程，如圖所示：
抓包得後如圖所示，可以看到客戶端的整個加密過程：
在 TLS 1.3 中，客戶端首先不僅傳送 ClientHello 支援的密碼列表，而且還猜測伺服器將選擇哪種金鑰協商演算法，併發送金鑰共享,這可以節省很大一部分的開銷，從而提高了速度。
TLS1.3 提供 1-RTT 的握手機制，還是以 ECDHE 金鑰交換過程為例，握手過程如下。將客戶端傳送 ECDH 臨時公鑰的過程提前到 ClientHello ，同時刪除了 ChangeCipherSpec 協議簡化握手過程，使第一次握手時只需要1-RTT，來看具體的流程：
- 客戶端傳送 ClientHello 訊息，該訊息主要包括客戶端支援的協議版本、DH金鑰交換引數列表KeyShare;
- 服務端回覆 ServerHello，包含選定的加密套件;傳送證書給客戶端;使用證書對應的私鑰對握手訊息簽名，將結果傳送給客戶端;選用客戶端提供的引數生成 ECDH 臨時公鑰，結合選定的 DH 引數計算出用於加密 HTTP 訊息的共享金鑰;服務端生成的臨時公鑰通過 KeyShare 訊息傳送給客戶端;
- 客戶端接收到 KeyShare 訊息後，使用證書公鑰進行簽名驗證，獲取伺服器端的 ECDH 臨時公鑰，生成會話所需要的共享金鑰;
- 雙方使用生成的共享金鑰對訊息加密傳輸，保證訊息安全。
如果客戶端之前已經連線，我們有辦法在 1.2 中進行 1-RTT 連線，而在 TLS 1.3 中允許我們執行 0-RTT連線，如圖所示：
當然，具體採用 TLS1.2 還是 TLS1.3 需要根據實際的業務場景和使用者群體來決定，在較新版本的瀏覽器一般都支援最新的加密協議，而類似 IE 8 以及Windows xp 這種古老的瀏覽器和作業系統就不支援了。如果說你的使用者是一些政府部門的客戶，那麼就不適合採用這種較新的技術方案了，因為據我所知很多政府部門的作業系統還是xp和 IE 8以下的版本，這會導致新協議無法在他們的作業系統中正常工作。因此你可以講加密演算法和加密協議多配置幾個，向下相容不同客戶端。
第四，證書要從可靠的CA廠商申請，因為不可靠的廠商(比如不被主流瀏覽器信任的證書廠商)會亂修改證書日期，重複簽發證書。此外即使是可靠的 CA 簽發的證書也有可能是偽造的，比如賽門鐵克之前就被曝出醜聞而被火狐和Chrome 懲罰，結果就是這些主流瀏覽器不在信任這些CA 機構簽發的一部分證書。因此一旦發現證書不受信任要儘快替換。
第五，使用完整的證書鏈，如果證書鏈不完整，則很有可能在一些版本的瀏覽器上訪問異常。
第六，使用HTTP/2，使用最新的 HTTP 2 可以提升網站的訪問速度以及擁有更好的效能支援。
第七，保護證書私鑰不被外洩。
第八，根據自己的業務需求選擇合適的證書，證書分為自簽證書、 DV、 EV 和OV 證書，一般來說只是需要進行簡單的資料加密，採用 DV 證書即可，這類證書通常都可以免費申請，只需要進行簡單的域名所有者權驗證即可申請，而EV和OV證書一般價格昂貴，適合金融機構或針對資料加密有嚴格要求的單位使用，這類證書籤發手續複雜，一般需要進行企業身份認證後才會簽發。自簽證書一般使用者臨時測試使用，不建議生產環境使用，因為它並不是受信任的CA 機構簽發的，瀏覽器不會信任。
當我們配置完後，可以通過https://www.ssllabs.com/ssltest/ ，對你的 HTTPS 站點進行評分，如果是A+則說明你的站點安全性特別高。如圖所示，如果評分不高，你可以檢視具體的詳情來針對你的站點進行更具體的優化。
最後，附上一份nginx 的配置，作為參考：
server
{
listen 443 ssl http2 default_server;
server_name www.example.com ;
index index.html index.htm index.php;
root /web;
ssl on;
ssl_certificate /nginx/ssl/awen/fullchain.cer;
ssl_certificate_key /nginx/ssl/example/example.com.key;
ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+ECDSA+AES128:EECDH+aRSA+AES128:RSA+AES128:EECDH+ECDSA+AES256:EECDH+aRSA+AES256:RSA+AES256:EECDH+ECDSA+3DES:EECDH+aRSA+3DES:RSA+3DES:TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:TLS-AES-128-GCM-SHA256:EECDH+CHACHA20:EECDH+AESGCM:EECDH+AES:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!KRB5:!aECDH:!EDH+3DES;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets on;
resolver 114.114.114.114 valid=300s;
resolver_timeout 10s;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
add_header X-Frame-Options deny;
add_header X-Content-Type-Options nosniff;
add_header CIP $http_x_real_ip;
add_header Accept-Ranges bytes;
}
server {
listen 80;
server_name _;
server_name www.example.com ;
return 302 https://$host$request_uri;
}
好了，以上就是我給大家分享的關於 HTTPS 站點的優化建議。