正文

這篇乾貨不錯，把HTTPS的原理講清楚了，而且容易懂，建議大家好好讀一下。

HTTPS

隨著 HTTPS 建站的成本下降，現在大部分的網站都已經開始用上 HTTPS 協議。大家都知道 HTTPS 比 HTTP 安全，也聽說過與 HTTPS 協議相關的概念有 SSL 、非對稱加密、 CA證書等，但對於以下靈魂三拷問可能就答不上了：

1. 為什麼用了 HTTPS 就是安全的？

2. HTTPS 的底層原理如何實現？

3. 用了 HTTPS 就一定安全嗎？

本文將層層深入，從原理上把 HTTPS 的安全性講透。

HTTPS 的實現原理

大家可能都聽說過 HTTPS 協議之所以是安全的是因為 HTTPS 協議會對傳輸的資料進行加密，而加密過程是使用了非對稱加密實現。但其實，HTTPS 在內容傳輸的加密上使用的是對稱加密，非對稱加密只作用在證書驗證階段。

HTTPS的整體過程分為證書驗證和資料傳輸階段，具體的互動過程如下：

① 證書驗證階段

1. 瀏覽器發起 HTTPS 請求

2. 服務端返回 HTTPS 證書

3. 客戶端驗證證書是否合法，如果不合法則提示告警

② 資料傳輸階段

1. 當證書驗證合法後，在本地生成隨機數

2. 透過公鑰加密隨機數，並把加密後的隨機數傳輸到服務端

3. 服務端透過私鑰對隨機數進行解密

4. 服務端透過客戶端傳入的隨機數構造對稱加密演算法，對返回結果內容進行加密後傳輸

為什麼資料傳輸是用對稱加密？

首先，非對稱加密的加解密效率是非常低的，而 http 的應用場景中通常端與端之間存在大量的互動，非對稱加密的效率是無法接受的；

另外，在 HTTPS 的場景中只有服務端儲存了私鑰，一對公私鑰只能實現單向的加解密，所以 HTTPS 中內容傳輸加密採取的是對稱加密，而不是非對稱加密。

為什麼需要 CA 認證機構頒發證書？

HTTP 協議被認為不安全是因為傳輸過程容易被監聽者勾線監聽、偽造伺服器，而 HTTPS 協議主要解決的便是網路傳輸的安全性問題。

首先我們假設不存在認證機構，任何人都可以製作證書，這帶來的安全風險便是經典的“中間人攻擊”問題。

“中間人攻擊”的具體過程如下：

過程原理：

1. 本地請求被劫持（如DNS劫持等），所有請求均傳送到中間人的伺服器

2. 中間人伺服器返回中間人自己的證書

3. 客戶端建立隨機數，透過中間人證書的公鑰對隨機數加密後傳送給中間人，然後憑隨機數構造對稱加密對傳輸內容進行加密傳輸

4. 中間人因為擁有客戶端的隨機數，可以透過對稱加密演算法進行內容解密

5. 中間人以客戶端的請求內容再向正規網站發起請求

6. 因為中間人與伺服器的通訊過程是合法的，正規網站透過建立的安全通道返回加密後的資料

7. 中間人憑藉與正規網站建立的對稱加密演算法對內容進行解密

8. 中間人透過與客戶端建立的對稱加密演算法對正規內容返回的資料進行加密傳輸

9. 客戶端透過與中間人建立的對稱加密演算法對返回結果資料進行解密

由於缺少對證書的驗證，所以客戶端雖然發起的是 HTTPS 請求，但客戶端完全不知道自己的網路已被攔截，傳輸內容被中間人全部竊取。

瀏覽器是如何確保 CA 證書的合法性？

1. 證書包含什麼資訊？

• 頒發機構資訊

• 公鑰

• 公司資訊

• 域名

• 有效期

• 指紋

• ......

2. 證書的合法性依據是什麼？

首先，權威機構是要有認證的，不是隨便一個機構都有資格頒發證書，不然也不叫做權威機構。另外，證書的可信性基於信任制，權威機構需要對其頒發的證書進行信用背書，只要是權威機構生成的證書，我們就認為是合法的。所以權威機構會對申請者的資訊進行稽核，不同等級的權威機構對稽核的要求也不一樣，於是證書也分為免費的、便宜的和貴的。

3. 瀏覽器如何驗證證書的合法性？

瀏覽器發起 HTTPS 請求時，伺服器會返回網站的 SSL 證書，瀏覽器需要對證書做以下驗證：

1. 驗證域名、有效期等資訊是否正確。證書上都有包含這些資訊，比較容易完成驗證；

2. 判斷證書來源是否合法。每份簽發證書都可以根據驗證鏈查詢到對應的根證書，作業系統、瀏覽器會在本地儲存權威機構的根證書，利用本地根證書可以對對應機構簽發證書完成來源驗證；

   
   

3. 判斷證書是否被篡改。需要與 CA 伺服器進行校驗；

4. 判斷證書是否已吊銷。透過CRL（Certificate Revocation List 證書登出列表）和 OCSP（Online Certificate Status Protocol 線上證書狀態協議）實現，其中 OCSP 可用於第3步中以減少與 CA 伺服器的互動，提高驗證效率

以上任意一步都滿足的情況下瀏覽器才認為證書是合法的。

這裡插一個我想了很久的但其實答案很簡單的問題：

既然證書是公開的，如果要發起中間人攻擊，我在官網上下載一份證書作為我的伺服器證書，那客戶端肯定會認同這個證書是合法的，如何避免這種證書冒用的情況？

其實這就是非加密對稱中公私鑰的用處，雖然中間人可以得到證書，但私鑰是無法獲取的，一份公鑰是不可能推算出其對應的私鑰，中間人即使拿到證書也無法偽裝成合法服務端，因為無法對客戶端傳入的加密資料進行解密。

4. 只有認證機構可以生成證書嗎？

如果需要瀏覽器不提示安全風險，那隻能使用認證機構簽發的證書。但瀏覽器通常只是提示安全風險，並不限制網站不能訪問，所以從技術上誰都可以生成證書，只要有證書就可以完成網站的 HTTPS 傳輸。例如早期的 12306 採用的便是手動安裝私有證書的形式實現 HTTPS 訪問。

本地隨機數被竊取怎麼辦？

證書驗證是採用非對稱加密實現，但是傳輸過程是採用對稱加密，而其中對稱加密演算法中重要的隨機數是由本地生成並且儲存於本地的，HTTPS 如何保證隨機數不會被竊取？

其實 HTTPS 並不包含對隨機數的安全保證，HTTPS 保證的只是傳輸過程安全，而隨機數儲存於本地，本地的安全屬於另一安全範疇，應對的措施有安裝防毒軟體、反木馬、瀏覽器升級修復漏洞等。

用了 HTTPS 會被抓包嗎？

HTTPS 的資料是加密的，常規下抓包工具代理請求後抓到的包內容是加密狀態，無法直接檢視。

但是，正如前文所說，瀏覽器只會提示安全風險，如果使用者授權仍然可以繼續訪問網站，完成請求。因此，只要客戶端是我們自己的終端，我們授權的情況下，便可以組建中間人網路，而抓包工具便是作為中間人的代理。通常 HTTPS 抓包工具的使用方法是會生成一個證書，使用者需要手動把證書安裝到客戶端中，然後終端發起的所有請求透過該證書完成與抓包工具的互動，然後抓包工具再轉發請求到伺服器，最後把伺服器返回的結果在控制檯輸出後再返回給終端，從而完成整個請求的閉環。

既然 HTTPS 不能防抓包，那 HTTPS 有什麼意義？

HTTPS 可以防止使用者在不知情的情況下通訊鏈路被監聽，對於主動授信的抓包操作是不提供防護的，因為這個場景使用者是已經對風險知情。要防止被抓包，需要採用應用級的安全防護，例如採用私有的對稱加密，同時做好移動端的防反編譯加固，防止本地演算法被破解。

總結

以下用簡短的Q&A形式進行全文總結：

Q: HTTPS 為什麼安全？

A: 因為 HTTPS 保證了傳輸安全，防止傳輸過程被監聽、防止資料被竊取，可以確認網站的真實性。

Q: HTTPS 的傳輸過程是怎樣的？

A: 客戶端發起 HTTPS 請求，服務端返回證書，客戶端對證書進行驗證，驗證透過後本地生成用於改造對稱加密演算法的隨機數，透過證書中的公鑰對隨機數進行加密傳輸到服務端，服務端接收後透過私鑰解密得到隨機數，之後的資料互動透過對稱加密演算法進行加解密。

Q: 為什麼需要證書？

A: 防止”中間人“攻擊，同時可以為網站提供身份證明。

Q: 使用 HTTPS 會被抓包嗎？

A: 會被抓包，HTTPS 只防止使用者在不知情的情況下通訊被監聽，如果使用者主動授信，是可以構建“中間人”網路，代理軟體可以對傳輸內容進行解密。

順手 po 一張學習的過程圖。

最後

Android 發展至今，競爭日趨激烈，衝擊更高的職位，才有更高的收入！而我們Android程式設計師，要學的東西有很多，要想不被環境淘汰就只有不斷提升自己，從來都是我們去適應環境，而不是環境來適應我們！