服務端指南 | HTTPS 項目實戰指南

本文將重點介紹關於 HTTPS 的幾個實戰指南。

原文地址：服務端指南 | HTTPS 項目實戰指南
博客地址：blog.720ui.com/

本文將重點介紹關於 HTTPS 的幾個實戰指南。

1. HTTPS 使用剖析
2. HTTPS 項目場景
3. HTTPS 設計上的借鑑
4. HTTPS 降級攻擊

HTTPS 使用剖析與項目場景

HTTP 協議沒有加密機制，能夠經過 SSL 或 TLS 加密 HTTP 的通訊內容。所以，HTTPS 是 HTTP 的安全版，在 HTTP 協議中加入 SSL 層，它由兩部分組成：HTTP 與 SSL。其中，SSL 是獨立於 HTTP 的協議，它不只能夠適用於 HTTP 協議，還能夠配合 WebSocket 等協議一塊兒使用。

爲何使用 HTTPS

HTTP 協議沒有加密機制，通訊內容是明文傳輸的，沒有通過任何安全處理。然而，互聯網的任何角落均可能存在通訊內容在傳輸過程當中被中間者竊聽、篡改、冒充等風險。其中，任何角落指的是用戶的通訊內容在瀏覽器和服務器中間傳輸必需要通過的節點，好比 WIFI 熱點，路由器，防火牆，反向代理，緩存服務器等。所以，HTTP 協議通訊存在的威脅不言而喻，中間者能夠竊聽隱私，使用戶的敏感信息泄露；篡改網頁，例如中間者向頁面插入廣告內容，甚至有的中間者進行流量劫持，例若有的時候會發現域名沒有輸錯，結果卻跳轉到了一個釣魚網站，由於這個網站被中間者劫持了。

所以，爲了解決竊聽、篡改、冒充等風險，HTTPS 的價值就體現出來了，HTTPS 能夠進行通訊內容加密，使第三方沒法竊聽。HTTPS 能夠進行身份認證，一旦通訊內容被篡改，通訊雙方會馬上發現。此外，HTTPS 能夠保證通訊內容的完整性，防止通訊內容冒充或者篡改。

SSL 與 TLS

HTTP 協議能夠經過 SSL 或 TLS 加密 HTTP 的通訊內容。其中，SSL 最初由網景通訊公司率先倡導與開發，最新版本是 SSL 3.0。目前，由 IETF 主導與管理。IETF 以 SSL 3.0 爲基準，在 SSL 3.0 協議規範之上又制定了 TLS 1.0、 TLS 1.1 和 TLS 1.2。

HTTPS 原理剖析

爲了更好地理解 HTTPS，先來觀察一下 HTTPS 的通訊步驟。

第一步，用戶在瀏覽器裏輸入一個支持 HTTPS 協議的網址，例如 blog.720ui.com，此時會發起一個 HTTPS 請求，經過 TCP 和服務器創建鏈接，其中使用 443 端口。

第二步，服務器向客戶端發送證書，其中包括域名，申請證書的公司，證書的公鑰等信息。

第三步，客戶端經過 SSL 或 TLS 對證書進行解析，驗證公鑰是否有效，例如驗證頒發機構與驗證過時時間等信息，若是發現證書異常，則會彈出一個警告框，提示證書存在問題。若是證書沒有問題，那麼就生成一個密鑰，而後向服務器發送證書公鑰加密後的密鑰。

第四步，服務器用證書私鑰進行解密，得到客戶端傳過來的密鑰。

第五步，服務器用客戶端的密鑰加密後的信息發送給客戶端。

第六步，客戶端用密鑰解密服務端傳過來的信息，驗證服務端傳過來的信息是否能夠用密鑰進行解密。

第七步，客戶端用密鑰加密請求內容，而後將通訊內容發送給服務端。

第六步，服務端用密鑰解密請求內容，並進行業務處理後用密鑰加密響應內容，而後將通訊內容發送給客戶端。

在以上流程中，HTTPS 協議將對稱加密算法與非對稱加密算法的優點相結合。使用對稱加密算法對通訊內容進行快速加密，從而彌補了非對稱加密算法處理速度慢的問題，並保證通訊內容的機密性。同時，使用非對稱加密算法將對稱加密算法的密鑰進行加密，保證對稱加密算法的密鑰的安全交換。所以，HTTPS 協議先經過非對稱加密算法進行密鑰的安全交換，並在創建通訊鏈接後，使用對稱加密算法進行通訊，保證通訊內容的機密性。

HTTPS 項目場景

真實的業務場景是比較複雜的。這裏，整理 3 個項目中遇到的比較複雜的應用場景。

對 HTTPS 協議的通訊內容進行 CDN 加速

對 HTTPS 協議的通訊內容進行 CDN 加速主要兩個方案。

方案一，服務器（源站）提供證書給 CDN 廠商，包括證書公鑰和證書私鑰，CDN 負責內容緩存，CDN 有緩存則直接響應，以 HTTP 或 HTTPS 的形式回源。這個方案，適用僅對防劫持、防篡改有需求，而願意提供證書給 CDN 的源站加速。

方案二，服務器（源站）不提供證書給 CDN 廠商，所以 CDN 須要存放證書公鑰，服務器（源站）存放證書私鑰。在 CDN 與瀏覽器進行 TLS 的認證和密鑰協商過程當中，經過安全的信道把協商過程當中的信息以 HTTP 或 HTTPS 的形式轉發給源網站。這個方案，CDN 不作緩存，僅以自有的加速網絡，將用戶的請求快速送到服務器（源站），下降公網延遲。所以，這個方案適用於對安全要求更高，不肯將證書私鑰共享給 CDN 的源站加速。

對 HTTPS 的域名經過 CNAME 綁定到另一個 HTTPS 域名上

對 HTTPS 的域名經過 CNAME 綁定到另一個 HTTPS 域名上，這個狀況下，須要兩個證書，由於每一個證書跟本身的域名進行綁定，即便它們都在同一個服務器上，也不能使用同一個證書。

兩臺服務器的證書問題

由於安全問題，CA 證書部署在一臺服務器上面，可是業務系統部署在另一臺服務器上面，這種狀況就比較難辦。此時，須要藉助 Nginx 進行反向代理，回源到具體的服務器。

HTTPS 設計上的借鑑

對稱加密算法能夠將敏感的信息在通訊過程當中經過 DES 或 AES 進行加密傳輸，而後在客戶端和服務端直接進行解密。可是，將密鑰編碼在代碼中存在安全隱患，由於密鑰可能會泄漏。所以，更安全的作法是將密鑰保存在數據庫中，由服務端的接口下發密鑰，在使用時由客戶端獲取密鑰並加載進內存，而且經過非對稱加密算法保證密鑰在通訊過程當中的安全交換。實際上，這個通訊流程能夠借鑑 HTTPS 協議的流程，將對稱加密算法與非對稱加密算法的優點相結合。其中，使用對稱加密算法對通訊內容進行快速加密，從而彌補了非對稱加密算法處理速度慢的問題，並保證通訊內容的機密性。同時，使用非對稱加密算法將對稱加密算法的密鑰進行加密，保證對稱加密算法的密鑰的安全交換。

這裏，介紹一個文件加密與解密的真實案例。需求場景是爲了防止平臺資源被第三方抓取，所以須要對平臺的資源進行加密，而且只能用於平臺的客戶端使用。爲了更好地理解整個通訊流程，先來觀察一下加密的通訊步驟。

第一步，客戶端 SDK 使用 RSA 加密算法，生成一對公私鑰，或者稱之爲加密密鑰與解密密鑰。

第二步，客戶端 SDK 向服務端請求 AES 密鑰，由於密鑰保存在服務器的數據庫中，由服務端的接口下發密鑰。其中，請求參數包括資源 ID 與 RSA 加密算法的公鑰。

第三步，服務端使用客戶端 SDK請求參數中的資源 ID，生成一個 AES 密鑰，並保存到數據庫中。

第四步，服務端使用客戶端 SDK請求參數中的 RSA 加密算法的公鑰，加密AES 密鑰。

第五步，服務器發送給客戶端 SDK加密後的 AES 密鑰。

第六步，客戶端 SDK 使用RSA 加密算法的私鑰解密，獲取到真正的 AES 密鑰。

第七步，客戶端 SDK 使用真正的 AES 密鑰對資源文件進行加密。

理解了資源文件的加密的通訊流程，再來觀察一下解密的通訊步驟。

與資源文件的加密的通訊流程相似，客戶端 SDK 使用 RSA 加密算法，生成一對公私鑰，客戶端 SDK 向服務端請求 AES 密鑰，服務端使用客戶端 SDK請求參數中的資源 ID 查詢 AES 密鑰，服務端使用客戶端 SDK請求參數中的 RSA 加密算法的公鑰，加密AES 密鑰，而且服務器發送給客戶端 SDK加密後的 AES 密鑰，客戶端 SDK 使用RSA 加密算法的私鑰解密，獲取到真正的 AES 密鑰，最後，客戶端 SDK 使用真正的 AES 密鑰對資源文件進行解密。

HTTPS 降級攻擊的場景剖析與解決之道

HTTPS 必定安全麼

HTTP 協議沒有加密機制，通訊內容是明文傳輸的，沒有通過任何安全處理。所以，爲了解決竊聽、篡改、冒充等風險，採用 HTTPS 協議。HTTPS 能夠進行通訊內容加密，使第三方沒法竊聽。HTTPS 能夠進行身份認證，一旦通訊內容被篡改，通訊雙方會馬上發現。此外，HTTPS 能夠保證通訊內容的完整性，防止通訊內容冒充或者篡改。那麼，使用了 HTTPS 就能確保通訊內容的安全傳輸嗎？理論上，是這樣的，可是事實上，現實卻不是如此，由於設計與實現 SSL/TLS 協議出現了漏洞，致使攻擊者一樣能夠攻擊一些舊版本的 SSL/TLS 協議。這其中就包括 SSL 3.0。

什麼是 HTTPS 降級攻擊

由於瀏覽器的兼容性問題，當瀏覽器進行 HTTPS 鏈接失敗的時候，將會嘗試使用舊的協議版本，因而加密協議由更加安全的協議，好比 TLS 1.2 降級成 SSL 3.0。所以，在 HTTPS 降級攻擊中，攻擊者利用舊版本的 SSL/TLS 協議的漏洞，其中包括 SSL 3.0 的漏洞，而後攻擊者獲取安全鏈接當中某些能夠降級成 SSL 3.0 的加密後的明文的通訊內容進行攻擊。

注意的是，若是服務器支持 SSL 3.0 協議，同時，攻擊者又能做爲中間人控制瀏覽器發起漏洞版本的 HTTPS 請求，此時，雖然攻擊者竊聽到加密的通訊內容，但加密的協議存在漏洞，能夠進行降級攻擊，解密這些加密的通訊內容能夠獲取有價值的信息，例如用戶的隱私數據。

HTTPS 降級攻擊的解決之道

目前，解決 HTTPS 降級攻擊的惟一方法是禁用 SSL 3.0 協議，並防止 TLS 1.2 協議、 TLS 1.1 協議與 TLS 1.0 協議降級到 SSL 3.0 協議。其中，禁用 SSL 3.0 協議的策略有不少，這裏主要介紹下 Nginx 如何防止 TLS 1.2 協議、 TLS 1.1 協議與 TLS 1.0 協議降級到 SSL 3.0 協議如下版本，從而防止 HTTPS 降級攻擊。

Nginx 原先的配置，以下所示。此時，若是 Nginx 原先的配置沒有額外的配置，那麼在 Nginx 中隱性默認是 SSLv3 TLSv1 TLSv1.1 TLSv1.2。

ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;複製代碼

Nginx 禁用 SSL 3.0 協議，並防止 TLS 1.2 協議、 TLS 1.1 協議與 TLS 1.0 協議降級到 SSL 3.0 協議的配置很是簡單，只須要屏蔽 SSLv3 參數便可，以下所示。

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;複製代碼

總結下，HTTPS 能確保通訊內容的安全傳輸嗎？答案是不必定，由於設計與實現 SSL/TLS 協議出現了漏洞，致使攻擊者一樣能夠攻擊一些舊版本的 SSL/TLS 協議，其中就包括 SSL 3.0，可能會被攻擊者進行 HTTPS 的降級攻擊。所以，SSL 3.0 協議並不安全，爲了防止 HTTPS 的降級攻擊，須要禁用 SSL 3.0 協議，確保TLS 1.2 協議、 TLS 1.1 協議與 TLS 1.0 協議降級到 SSL 3.0 協議如下版本。

（完）

更多精彩文章，盡在「服務端思惟」微信公衆號！