HTTPS 原理剖析與專案場景

最近手頭有兩個專案，XX導航和XX產業平臺，都需要使用HTTPS協議，因此，這次對HTTPS協議做一次整理與分享。

為什麼使用HTTPS

HTTP 協議，本身是明文傳輸的，沒有經過任何安全處理。那麼這個時候就很容易在傳輸過程中被中間者竊聽、篡改、冒充等風險。這裡提到的中間者主要指一些網路節點，是使用者資料在瀏覽器和伺服器中間傳輸必須要經過的節點，比如 WIFI 熱點，路由器，防火牆，反向代理，快取伺服器等。

HTTP 協議，中間者可以竊聽隱私，使使用者的敏感資料暴露無遺；篡改網頁，例如往頁面插的廣告內容，甚至進行流量劫持，比如有的時候你會發現域名沒輸錯，結果卻跑到了一個釣魚網站上，因為被它劫持了。

為了解決這三大風險，HTTPS的價值就體現出來了。

• 內容加密，第三方無法竊聽。
• 身份認證，一旦被篡改，通訊雙方會立刻發現。
• 資料完整性。防止內容冒充或者篡改。

什麼是HTTPS

HTTPS，簡單的理解HTTP的安全版，即HTTP下加入SSL層，由兩部分組成：HTTP + SSL / TLS。

HTTPS原理剖析

第一步，使用者在瀏覽器裡輸入一個https網址，此時客戶端發起HTTPS請求，通過TCP和伺服器建立連線（443埠）。

第二步，伺服器存放CA證書進行處理，注意的是採用HTTPS協議的伺服器必須要有一套數字證書，這套證書其實就是一對公鑰和私鑰。

第三步，伺服器向客戶端返回證書。證書裡面包含了很多資訊：比如域名，申請證書的公司，公鑰等。以下是一個淘寶網的CA證書。

第四步，客戶端對證書進行解析。這部分工作是有客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發機構，過期時間等，如果發現異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那麼就生成一個隨機數，然後用證書對該隨機數進行加密。

第五步，向伺服器傳送證書加密後的隨機數。

第六步，伺服器用它的私鑰進行解密，得到了客戶端傳過來的隨機數。

第七步，伺服器用客戶端的隨機數加密後的資訊傳送給客戶端。

第八步，客戶端用之前生成的金鑰解密服務端傳過來的資訊。

以上就是整個HTTPS的互動過程，大家是不是對整個流程有了比較大致的瞭解了呢。

HTTPS的相關場景

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

場景一，對HTTPS進行CDN加速

這種情況下，CA證書需要存放在哪裡呢？

主要兩個方案。

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

方案二：伺服器（源站）不提供證書，CDN存放公鑰，伺服器（源站）存放私鑰。在CDN與前端瀏覽器進行TLS的認證和祕鑰協商過程中，通過安全的通道把協商過程中的資訊以HTTP或HTTPS的形式轉發給源網站。此方案中，CDN不做快取，僅以自有的加速網路，將使用者的請求快速送到伺服器（源站），降低公網延遲。這個方案，適用於對安全要求更高，不願將私鑰共享給CDN的源站加速。

場景二，對HTTPS的域名通過CNAME繫結到另外一個HTTPS域名上

這個情況下，我們需要一個證書還是兩個證書呢？

我們的方案是，兩個證書。因為每個證書跟自己的域名進行繫結，即使它們都在同一個伺服器上，也不能使用同一個證書。

場景三，兩臺伺服器的證書問題

因為安全問題，CA證書在一臺伺服器上，而服務部署在另外一臺伺服器上。這種情況就比較難辦。

此時，需要藉助Nginx進行反向代理，回源到具體的伺服器。

HTTPS設計上的借鑑

對於HTTPS設計上的方案，對於我們而言，有什麼可以借鑑的地方麼？

答案是肯定的：有。一個非常典型的方案就是RSA雙向認證。

RSA雙向認證，顧名思義，就是用對方的公鑰加密是為了保密，這個只有對方用私鑰能解密。用自己的私鑰加密是為了防抵賴，能用我的公鑰解開，說明這是我發來的。例如，支付寶的支付介面就是非常典型的RSA雙向認證的安全方案。此外，我們之前的教育資源、敏感驗證碼出於安全性考慮都借鑑了這個方案。