你知道，HTTPS用的是對稱加密仍是非對稱加密？

一、引言

隨着互聯網安全意識的廣泛提升，對安全要求稍高的應用中，HTTPS的使用是很常見的，甚至在1年前，蘋果公司就將使用HTTPS做爲APP上架蘋果應用市場的先決條件之一（詳見：《蘋果即將強制實施 ATS，你的APP準備好切換到HTTPS了嗎？》）。

因此，不管是即時通信IM仍是其它應用，在網絡安全意識加強的今天，不少場景下使用HTTPS是確定沒錯的。對於即時通信IM的開發人員來講，長鏈接用TLS這沒疑問，短鏈接用HTTPS也沒問題，但我想問你一個最基礎的面視問題：HTTPS到底用的是對稱加密仍是非對稱加密？

要回答這個問題，顯然須要再梳理一下HTTPS的技術原理了，本文將帶你瞭解HTTPS到底用的是對稱加密仍是非對稱加密，以及具體又是怎麼使用的。

學習交流：

- 即時通信/推送技術開發交流5羣： 215477170 [推薦]
- 移動端IM開發入門文章：《 新手入門一篇就夠：從零開發移動端IM》

（本文同步發佈於：http://www.52im.net/thread-2866-1-1.html）

二、相關文章

➊ 要理解HTTPS，須對HTTP協議有所瞭解，如下文章多是您須要的：

《 網絡編程懶人入門(七)：深刻淺出，全面理解HTTP協議》
《 腦殘式網絡編程入門(三)：HTTP協議必知必會的一些知識》
《 鮮爲人知的網絡編程(八)：從數據傳輸層深度解密HTTP》
《 從HTTP/0.9到HTTP/2：一文讀懂HTTP協議的歷史演變和設計思路》
《 WebSocket詳解（四）：刨根問底HTTP與WebSocket的關係(上篇)》
《 WebSocket詳解（五）：刨根問底HTTP與WebSocket的關係(下篇)》
《 可能會搞砸你的面試：你知道一個TCP鏈接上能發起多少個HTTP請求嗎？》

➋ 想更好的理解本文有關HTTPS的知識，建議一併閱如下HTTPS的基礎文章：

《 一分鐘理解 HTTPS 到底解決了什麼問題》
《 即時通信安全篇（七）：若是這樣來理解HTTPS，一篇就夠了》
《 一篇讀懂HTTPS：加密原理、安全邏輯、數字證書等》
《 HTTPS時代已來，打算更新你的HTTP服務了嗎？》
《 美圖App的移動端DNS優化實踐：HTTPS請求耗時減少近半》

➌ 本文是IM通信安全知識系列文章中的第8篇，此係列總目錄以下：

《 即時通信安全篇（一）：正確地理解和使用Android端加密算法》
《 即時通信安全篇（二）：探討組合加密算法在IM中的應用》
《 即時通信安全篇（三）：經常使用加解密算法與通信安全講解》
《 即時通信安全篇（四）：實例分析Android中密鑰硬編碼的風險》
《 即時通信安全篇（五）：對稱加密技術在Android平臺上的應用實踐》
《 即時通信安全篇（六）：非對稱加密技術的原理與應用實踐》
《 即時通信安全篇（七）：若是這樣來理解HTTPS原理，一篇就夠了》
《 即時通信安全篇（八）：你知道，HTTPS用的是對稱加密仍是非對稱加密？》（本文）

三、HTTPS靈魂拷問

隨着 HTTPS 建站的成本降低，如今大部分的網站都已經開始用上 HTTPS 協議。你們都知道 HTTPS 比 HTTP 安全，也據說過與 HTTPS 協議相關的概念有 SSL 、非對稱加密、 CA證書等。

但對於如下靈魂三拷問可能就答不上了：

• 1）爲何用了 HTTPS 就是安全的？
• 2）HTTPS 的底層原理如何實現？
• 3）用了 HTTPS 就必定安全嗎？

不用擔憂，本文將在解答「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 證書的合法性？

7.1 證書包含什麼信息？

• 1）頒發機構信息；
• 2）公鑰；
• 3）公司信息；
• 4）域名；
• 5）有效期；
• 6）指紋；
• 7）......

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

• 1）首先：權威機構是要有認證的，不是隨便一個機構都有資格頒發證書，否則也不叫作權威機構；
• 2）另外：證書的可信性基於信任制，權威機構須要對其頒發的證書進行信用背書，只要是權威機構生成的證書，咱們就認爲是合法的。

因此權威機構會對申請者的信息進行審覈，不一樣等級的權威機構對審覈的要求也不同，因而證書也分爲免費的、便宜的和貴的。

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

瀏覽器發起 HTTPS 請求時，服務器會返回網站的 SSL 證書，瀏覽器須要對證書作如下驗證：

1）驗證域名、有效期等信息是否正確：證書上都有包含這些信息，比較容易完成驗證；

2）判斷證書來源是否合法：每份簽發證書均可以根據驗證鏈查找到對應的根證書，操做系統、瀏覽器會在本地存儲權威機構的根證書，利用本地根證書能夠對對應機構簽發證書完成來源驗證（以下圖所示）： 

3）判斷證書是否被篡改：須要與 CA 服務器進行校驗；

4）判斷證書是否已吊銷：經過CRL（Certificate Revocation List 證書註銷列表）和 OCSP（Online Certificate Status Protocol 在線證書狀態協議）實現，其中 OCSP 可用於第3步中以減小與 CA 服務器的交互，提升驗證效率。

以上任意一步都知足的狀況下瀏覽器才認爲證書是合法的。

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

既然證書是公開的，若是要發起中間人攻擊，我在官網上下載一份證書做爲個人服務器證書，那客戶端確定會認同這個證書是合法的，如何避免這種證書冒用的狀況？
其實這就是非加密對稱中公私鑰的用處，雖然中間人能夠獲得證書，但私鑰是沒法獲取的，一份公鑰是不可能推算出其對應的私鑰，中間人即便拿到證書也沒法假裝成合法服務端，由於沒法對客戶端傳入的加密數據進行解密。

7.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 只防止用戶在不知情的狀況下通訊被監聽，若是用戶主動授信，是能夠構建「中間人」網絡，代理軟件能夠對傳輸內容進行解密。

好了，迴歸到本文標的問題，咱們來總結回顧一下。

Q: HTTPS用的是對稱加密仍是非對稱加密？

Q: HTTPS 在內容傳輸的加密上使用的是對稱加密，非對稱加密只做用在證書驗證階段。

順手 po 一張學習的過程圖（點擊查看大圖）：

附錄：更多有關IM安全的文章

《 傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示》
《 理論聯繫實際：一套典型的IM通訊協議設計詳解（含安全層設計）》
《 微信新一代通訊安全解決方案：基於TLS1.3的MMTLS詳解》
《 來自阿里OpenIM：打造安全可靠即時通信服務的技術實踐分享》
《 簡述實時音視頻聊天中端到端加密（E2EE）的工做原理》
《 移動端安全通訊的利器——端到端加密（E2EE）技術詳解》
《 Web端即時通信安全：跨站點WebSocket劫持漏洞詳解(含示例代碼)》
《 通俗易懂：一篇掌握即時通信的消息傳輸安全原理》
《 IM開發基礎知識補課(四)：正確理解HTTP短鏈接中的Cookie、Session和Token》
《 快速讀懂量子通訊、量子加密技術》
《 即時通信安全篇（七）：若是這樣來理解HTTPS原理，一篇就夠了》
《 一分鐘理解 HTTPS 到底解決了什麼問題》
《 一篇讀懂HTTPS：加密原理、安全邏輯、數字證書等》
《 即時通信安全篇（八）：你知道，HTTPS用的是對稱加密仍是非對稱加密？》
>>  更多同類文章 ……

（本文同步發佈於：http://www.52im.net/thread-2866-1-1.html）