本文引用了作者“leapMie”的“HTTPS 原理分析——帶著疑問層層深入”一文內容，感謝原作者的文字。
1、引言隨著網際網路安全意識的普遍提高，對安全要求稍高的應用中，HTTPS的使用是很常見的，甚至在1年前，蘋果公司就將使用HTTPS作為APP上架蘋果應用市場的先決條件之一（詳見：《蘋果即將強制實施 ATS，你的APP準備好切換到HTTPS了嗎？》）。
所以，無論是即時通訊IM還是其它應用，在網路安全意識增強的今天，很多場景下使用HTTPS是肯定沒錯的。對於即時通訊IM的開發人員來說，長連線用TLS這沒疑問，短連線用HTTPS也沒問題，但我想問你一個最基礎的面視問題：HTTPS到底用的是對稱加密還是非對稱加密？
要回答這個問題，顯然需要再梳理一下HTTPS的技術原理了，本文將帶你了解HTTPS到底用的是對稱加密還是非對稱加密，以及具體又是怎麼使用的。
（本文同步釋出於：http://www.52im.net/thread-2866-1-1.html）
2、相關文章➊ 要理解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篇，此係列總目錄如下：
3、HTTPS靈魂拷問《即時通訊安全篇（一）：正確地理解和使用Android端加密演算法》
《即時通訊安全篇（二）：探討組合加密演算法在IM中的應用》
《即時通訊安全篇（三）：常用加解密演算法與通訊安全講解》
《即時通訊安全篇（四）：例項分析Android中金鑰硬編碼的風險》
《即時通訊安全篇（五）：對稱加密技術在Android平臺上的應用實踐》
《即時通訊安全篇（六）：非對稱加密技術的原理與應用實踐》
《即時通訊安全篇（七）：如果這樣來理解HTTPS原理，一篇就夠了》
《即時通訊安全篇（八）：你知道，HTTPS用的是對稱加密還是非對稱加密？》（本文）
隨著 HTTPS 建站的成本下降，現在大部分的網站都已經開始用上 HTTPS 協議。大家都知道 HTTPS 比 HTTP 安全，也聽說過與 HTTPS 協議相關的概念有 SSL 、非對稱加密、 CA證書等。
但對於以下靈魂三拷問可能就答不上了：
1）為什麼用了 HTTPS 就是安全的？
2）HTTPS 的底層原理如何實現？
3）用了 HTTPS 就一定安全嗎？
不用擔心，本文將在解答“HTTPS到底用的是對稱加密還是非對稱加密？”的同時層層深入，從原理上把 HTTPS 的安全性講透，您也將同時理解上述問題。
4、HTTPS 的實現原理大家可能都聽說過 HTTPS 協議之所以是安全的是因為 HTTPS 協議會對傳輸的資料進行加密，而加密過程是使用了非對稱加密實現。但其實：HTTPS 在內容傳輸的加密上使用的是對稱加密，非對稱加密只作用在證書驗證階段。
HTTPS的整體過程分為證書驗證和資料傳輸階段，具體的互動過程如下：
① 證書驗證階段：
1）瀏覽器發起 HTTPS 請求；
2）服務端返回 HTTPS 證書；
3）客戶端驗證證書是否合法，如果不合法則提示告警。
② 資料傳輸階段：
1）當證書驗證合法後，在本地生成隨機數；
2）通過公鑰加密隨機數，並把加密後的隨機數傳輸到服務端；
3）服務端通過私鑰對隨機數進行解密；
4）服務端通過客戶端傳入的隨機數構造對稱加密演算法，對返回結果內容進行加密後傳輸。
5、為什麼資料傳輸是用對稱加密？首先：非對稱加密的加解密效率是非常低的，而 http 的應用場景中通常端與端之間存在大量的互動，非對稱加密的效率是無法接受的。
另外：在 HTTPS 的場景中只有服務端儲存了私鑰，一對公私鑰只能實現單向的加解密，所以 HTTPS 中內容傳輸加密採取的是對稱加密，而不是非對稱加密。
6、為什麼需要 CA 認證機構頒發證書？HTTP 協議被認為不安全是因為傳輸過程容易被監聽者勾線監聽、偽造伺服器，而 HTTPS 協議主要解決的便是網路傳輸的安全性問題。
首先我們假設不存在認證機構，任何人都可以製作證書，這帶來的安全風險便是經典的“中間人攻擊”問題。
“中間人攻擊”的具體過程如下：
如上圖所以，過程原理如下：
1）本地請求被劫持（如DNS劫持等），所有請求均傳送到中間人的伺服器；
2）中間人伺服器返回中間人自己的證書；
3）客戶端建立隨機數，通過中間人證書的公鑰對隨機數加密後傳送給中間人，然後憑隨機數構造對稱加密對傳輸內容進行加密傳輸；
4）中間人因為擁有客戶端的隨機數，可以通過對稱加密演算法進行內容解密；
5）中間人以客戶端的請求內容再向正規網站發起請求；
6）因為中間人與伺服器的通訊過程是合法的，正規網站通過建立的安全通道返回加密後的資料；
7）中間人憑藉與正規網站建立的對稱加密演算法對內容進行解密；
8）中間人通過與客戶端建立的對稱加密演算法對正規內容返回的資料進行加密傳輸；
9）客戶端通過與中間人建立的對稱加密演算法對返回結果資料進行解密。
由於缺少對證書的驗證，所以客戶端雖然發起的是 HTTPS 請求，但客戶端完全不知道自己的網路已被攔截，傳輸內容被中間人全部竊取。
7、瀏覽器是如何確保 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 訪問：
8、本地隨機數被竊取怎麼辦？證書驗證是採用非對稱加密實現，但是傳輸過程是採用對稱加密，而其中對稱加密演算法中重要的隨機數是由本地生成並且儲存於本地的，HTTPS 如何保證隨機數不會被竊取？
其實 HTTPS 並不包含對隨機數的安全保證，HTTPS 保證的只是傳輸過程安全，而隨機數儲存於本地，本地的安全屬於另一安全範疇，應對的措施有安裝防毒軟體、反木馬、瀏覽器升級修復漏洞等。
9、用了 HTTPS 會被抓包嗎？HTTPS 的資料是加密的，常規下抓包工具代理請求後抓到的包內容是加密狀態，無法直接檢視。
但是，正如前文所說，瀏覽器只會提示安全風險，如果使用者授權仍然可以繼續訪問網站，完成請求。因此，只要客戶端是我們自己的終端，我們授權的情況下，便可以組建中間人網路，而抓包工具便是作為中間人的代理。通常 HTTPS 抓包工具的使用方法是會生成一個證書，使用者需要手動把證書安裝到客戶端中，然後終端發起的所有請求通過該證書完成與抓包工具的互動，然後抓包工具再轉發請求到伺服器，最後把伺服器返回的結果在控制檯輸出後再返回給終端，從而完成整個請求的閉環。
既然 HTTPS 不能防抓包，那 HTTPS 有什麼意義？
HTTPS 可以防止使用者在不知情的情況下通訊鏈路被監聽，對於主動授信的抓包操作是不提供防護的，因為這個場景使用者是已經對風險知情。要防止被抓包，需要採用應用級的安全防護，例如採用私有的對稱加密，同時做好移動端的防反編譯加固，防止本地演算法被破解。
10、本文小結以下用簡短的Q&A形式進行全文總結。
Q: HTTPS 為什麼安全？
A: 因為 HTTPS 保證了傳輸安全，防止傳輸過程被監聽、防止資料被竊取，可以確認網站的真實性。
Q: HTTPS 的傳輸過程是怎樣的？
A: 客戶端發起 HTTPS 請求，服務端返回證書，客戶端對證書進行驗證，驗證通過後本地生成用於改造對稱加密演算法的隨機數，通過證書中的公鑰對隨機數進行加密傳輸到服務端，服務端接收後通過私鑰解密得到隨機數，之後的資料互動通過對稱加密演算法進行加解密。
Q: 為什麼需要證書？
A: 防止”中間人“攻擊，同時可以為網站提供身份證明。
Q: 使用 HTTPS 會被抓包嗎？
A: 會被抓包，HTTPS 只防止使用者在不知情的情況下通訊被監聽，如果使用者主動授信，是可以構建“中間人”網路，代理軟體可以對傳輸內容進行解密。
好了，迴歸到本文標的問題，我們來總結回顧一下。
Q: HTTPS用的是對稱加密還是非對稱加密？
Q: HTTPS 在內容傳輸的加密上使用的是對稱加密，非對稱加密只作用在證書驗證階段。
附錄：更多有關IM安全的文章
《傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示》
《理論聯絡實際：一套典型的IM通訊協議設計詳解（含安全層設計）》
《來自阿里OpenIM：打造安全可靠即時通訊服務的技術實踐分享》
《簡述實時音視訊聊天中端到端加密（E2EE）的工作原理》
《移動端安全通訊的利器——端到端加密（E2EE）技術詳解》
《Web端即時通訊安全：跨站點WebSocket劫持漏洞詳解(含示例程式碼)》
《通俗易懂：一篇掌握即時通訊的訊息傳輸安全原理》
《IM開發基礎知識補課(四)：正確理解HTTP短連線中的Cookie、Session和Token》
《快速讀懂量子通訊、量子加密技術》
《即時通訊安全篇（七）：如果這樣來理解HTTPS原理，一篇就夠了》
《一分鐘理解 HTTPS 到底解決了什麼問題》
《一篇讀懂HTTPS：加密原理、安全邏輯、數字證書等》
《即時通訊安全篇（八）：你知道，HTTPS用的是對稱加密還是非對稱加密？》
>> 更多同類文章 ……
（本文同步釋出於：http://www.52im.net/thread-2866-1-1.html）