本文由ELab技術團隊分享，原題“探秘HTTPS”，有修訂和改動。
1、引言
對于IM開發者來說，IM里最常用的通信技術就是Socket長連接和HTTP短連接（通常一個主流im會是這兩種通信手段的結合）。從通信安全的角度來說，Socket長連接的安全性，就是基于SSL/TLS加密的TCP協議來實現的（比如微信的mmtls，見《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》）；而對于HTTP短連接的安全性，也就是HTTPS了。
到底什么是HTTPS？為什么要用HTTPS？今天就借此機會，跟大家一起深入學習一下HTTPS的相關知識，包括HTTP的發展歷程、HTTP遇到的問題、對稱與非對稱加密算法、數字簽名、第三方證書頒發機構等概念。
學習交流：
（本文已同步發布于：http://www.52im.net/thread-3897-1-1.html）
2、系列文章
本文是IM通訊安全知識系列文章中的第9篇，此系列總目錄如下：
3、寫在前面
說到HTTPS，那就得回到HTTP協議。
對于HTTP協議，大家肯定都熟得不能再熟了。那么HTTPS和HTTP的區別大家了解嗎？
對于這個經典的面試題，大部分人會這么回答：
- 1）HTTPS比HTTP多了一個S(Secure)：也就是說HTTPS是安全版的HTTP；
- 2）端口號不同：HTTP使用80端口，HTTPS使用443端口；
- 3）加密算法：HTTPS用的是非對稱加密算法。
上面的回答能給幾分？等看完本文我們可以再回頭來看下這個回答。
那么，HTTPS是如何實現安全的短連接數據傳輸呢？想徹底搞明白這個問題，還是要從HTTP的發展歷程說起 ......
4、HTTP協議回顧
4.1 基礎常識
HTTP是Hypertext Transfer Protocal 的縮寫，中文全稱是超文本傳輸協議（詳見《深入淺出，全面理解HTTP協議》）。
通俗了解釋就是：
- 1）超文本是指包含但不限于文本外的圖片、音頻、視頻等多媒體資源；
- 2）協議是通信雙方約定好的數據傳輸格式以及通信規則。
HTTP是TCP/IP協議簇的最高層——應用層協議：
瀏覽器和服務器在使用HTTP協議相互傳遞超文本數據時，將數據放入報文體內，同時填充首部（請求頭或響應頭）構成完整HTTP報文并交到下層傳輸層，之后每一層加上相應的首部（控制部分）便一層層的下發，最終由物理層將二進制數據以電信號的形式發送出去。
HTTP的請求如下圖所示：
HTTP報文結構如下：
4.2 發展歷程
HTTP的發展歷程如下：
由HTTP的發展歷程來看，最開始版本的HTTP(HTTP1.0)在每次建立TCP連接后只能發起一次HTTP請求，請求完畢就釋放TCP連接。
我們都知道TCP連接的建立需要經過三次握手的過程，而每次發送HTTP請求都需要重新建立TCP連接，毫無疑問是很低效的。所以HTTP1.1改善了這一點，使用長連接的機制，也就是“一次TCP連接，N次HTTP請求”。
HTTP協議的長連接和短連接，實質上是 TCP 協議的長連接和短連接。
在使用長連接的情況下，當一個網頁打開完成后，客戶端和服務器之間用于傳輸HTTP數據的TCP連接不會關閉，客戶端再次訪問這個服務器時，會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。實現長連接需要客戶端和服務端都支持長連接。
PS：對于IM開發者來說，為了與Socket長連接通道區分，通常認為HTTP就是“短連接”（雖然這個“短連接”不一定真的“短”）。
HTTP1.0若要開啟長連接，需要加上Connection: keep-alive請求頭。有關HTTP協議的詳細發展歷程可閱讀《一文讀懂HTTP協議的歷史演變和設計思路》一文。
4.3 安全問題
隨著HTTP越來越廣泛的使用，HTTP的安全性問題也逐漸暴露。
回憶一下多年前遍地都是的運營商劫持，當你訪問一個本來很正常的網頁，但頁面上卻莫名其妙出現了一些廣告標簽、跳轉腳本、欺騙性的紅包按鈕，甚至有時候本來要下載一個文件，最后下載下來卻變成了另外一個完全不同的東西，這些都是被運營商劫持了HTTP明文數據的現象。
下圖就是似曾相識的運營商劫持效果圖：
HTTP主要有以下3點安全性問題：
歸納一下就是：
- 1）數據保密性問題：因為HTTP無狀態，而且又是明文傳輸，所有數據內容都在網絡中裸奔，包用戶括身份信息、支付賬號與密碼。這些敏感信息極易泄露造成安全隱患；
- 2）數據完整性問題：HTTP數據包在到達目的主機前會經過很多轉發設備，每一個設備節點都可能會篡改或調包信息，無法驗證數據的完整性；
- 3）身份校驗問題：有可能遭受中間人攻擊，我們無法驗證通信的另一方就是我們的目標對象。
因此，為了保證數據傳輸的安全性，必須要對HTTP數據進行加密。
5、常見的加密方式
5.1 基本情況
常見的加密方式分為三種：
前兩種適合數據傳輸加密，而數字摘要不可逆的特性常被用于數字簽名。
接下來，我們逐一簡要學習一下這三種常見的加密方法。
5.2 對稱加密
對稱加密也稱為密鑰加密或單向加密，就是使用同一套密鑰來進行加密和解密。密鑰可以理解為加密算法。
對稱加密圖示如下：
廣泛使用的對稱加密有：
對稱加密算法的優缺點和適用場景：
- 1）優點：算法公開、簡單，加密解密容易，加密速度快，效率高；
- 2）缺點：相對來說不算特別安全，只有一把鑰匙，密文如果被攔截，且密鑰也被劫持，那么，信息很容易被破譯；
- 3）適用場景：加解密速度快、效率高，因此適用于大量數據的加密場景。由于如何傳輸密鑰是較為頭痛的問題，因此適用于無需進行密鑰交換的場景，如內部系統，事先就可以直接確定密鑰。
PS：可以在線體驗對稱加密算法，鏈接是：http://www.jsons.cn/textencrypt/
小知識：base64編碼也屬于對稱加密哦！
5.3 非對稱加密
非對稱加密使用一對密鑰（公鑰和私鑰）進行加密和解密。
非對稱加密可以在不直接傳遞密鑰的情況下，完成解密，具體步驟如下：
- 1）乙方生成兩把密鑰（公鑰和私鑰）。公鑰是公開的，任何人都可以獲得，私鑰則是保密的；
- 2）甲方獲取乙方的公鑰，然后用它對信息加密；
- 3）乙方得到加密后的信息，用私鑰解密。
以最典型的非對稱加密算法RSA為例，舉個例子：
想要徹底搞懂RSA，需要了解數論的知識，全部推導過程RSA加密算法。簡單介紹思路：使用兩個超大質數以及其乘積作為生成公鑰和私鑰的材料，想要從公鑰推算出私鑰是非常困難的（需要對超大數因式分解為兩個很大質數的乘積）。目前被破解的最長RSA密鑰是768個二進制位。也就是說，長度超過768位的密鑰，還無法破解（至少沒人公開宣布）。因此可以認為，1024位的RSA密鑰基本安全，2048位的密鑰極其安全。
非對稱加密算法的優缺點和適用場景：
- 1）優點：強度高、安全性強于對稱加密算法、無需傳遞私鑰導致沒有密鑰泄露風險；
- 2）缺點：計算量大、速度慢；
- 3）適用場景：適用于需要密鑰交換的場景，如互聯網應用，無法事先約定密鑰。
實踐應用過程中，其實可以與對稱加密算法結合：
- 1）利用非對稱加密算法安全性較好的特點來傳遞對稱加密算法的密鑰。
- 2）利用對稱加密算法加解密速度快的特點，進行數據內容比較大的加密場景的加密（如HTTPS）。
PS：對于IM開發者來說，《探討組合加密算法在IM中的應用》一文值得一讀。
5.4 如何選擇？
1）如果選擇對稱加密：
HTTP請求方使用對稱算法加密數據，那么為了接收方能夠解密，發送方還需要把密鑰一同傳遞到接收方。在傳遞密鑰的過程中還是可能遭到嗅探攻擊，攻擊者竊取密鑰后依然可以解密從而得到發送的數據，所以這種方案不可行。
2）如果選擇非對稱加密：
接收方保留私鑰，把公鑰傳遞給發送方。發送方用公鑰來加密數據，接收方使用私鑰解密數據。攻擊者雖然不能直接獲取這些數據（因為沒有私鑰），但是可以通過攔截傳遞的公鑰，然后把自己的公鑰傳給發送方，再用自己的私鑰對發送方發送數據進行解密。
整個過程通信雙方都不知道中間人的存在，但是中間人能夠獲得完整的數據信息。
3）兩種加密方法的混合：
先使用非對稱加密算法加密并傳遞對稱加密的密鑰，然后雙方通過對稱加密方式加密要發送的數據。看起來沒什么問題，但事實是這樣嗎？
中間人依然可以攔截公鑰的傳遞，并以自己的公鑰作為替換，治標不治本。
想要治本，就要找到一個第三方公證人來證明公鑰沒有被替換，因此就引出了數字證書的概念，這也是下一節將分享的內容。
6、數字證書
6.1 CA機構
CA就是 Certificate Authority，即頒發數字證書的機構。
作為受信任的第三方，CA承擔公鑰體系中公鑰的合法性檢驗的責任。
證書就是源服務器向可信任的第三方機構申請的數據文件。這個證書除了表明這個域名是屬于誰的，頒發日期等，還包括了第三方證書的私鑰。
服務器將公鑰放在數字證書中，只要證書是可信的，公鑰就是可信的。
下面兩圖是飛書域名的證書中部分內容的信：
6.2 數字簽名
摘要算法：一般用哈希函數來實現，可以理解成一種定長的壓縮算法，它能把任意長度的數據壓縮到固定長度。這好比是給數據加了一把鎖，對數據有任何微小的改動都會使摘要變得截然不同。
通常情況下：數字證書的申請人（服務器）將生成由私鑰和公鑰以及證書請求文件（Certificate Signing Request，CSR）組成的密鑰對。CSR是一個編碼的文本文件，其中包含公鑰和其他將包含在證書中的信息（例如：域名、組織、電子郵件地址等）。密鑰對和CSR生成通常在將要安裝證書的服務器上完成，并且 CSR 中包含的信息類型取決于證書的驗證級別。與公鑰不同，申請人的私鑰是安全的，永遠不要向 CA（或其他任何人）展示。
生成 CSR 后：申請人將其發送給 CA，CA 會驗證其包含的信息是否正確，如果正確，則使用頒發的私鑰對證書進行數字簽名，然后將簽名放在證書內隨證書一起發送給申請人。
在SSL握手階段：瀏覽器在收到服務器的證書后，使用CA的公鑰進行解密，取出證書中的數據、數字簽名以及服務器的公鑰。如果解密成功，則可驗證服務器身份真實。之后瀏覽器再對數據做Hash運算，將結果與數字簽名作對比，如果一致則可以認為內容沒有收到篡改。
對稱加密和非對稱加密是公鑰加密、私鑰解密， 而數字簽名正好相反——是私鑰加密（簽名）、公鑰解密（驗證），如下圖所示。
限于篇幅，關于數字證書的內容本文就不再贅述，想詳細了解的可以閱讀：
7、為什么要使用HTTPS
《圖解HTTP》一書中提到HTTPS就是身披SSL外殼的HTTP。
7.1 SSL
SSL 在1999年被更名為TLS。
所以說：HTTPS 并不是一項新的應用層協議，只是 HTTP 通信接口部分由 SSL 和 TLS 替代而已。
具體就是：HTTP 會先直接和 TCP 進行通信，而HTTPS 會演變為先和 SSL 進行通信，然后再由 SSL 和 TCP 進行通信。
SSL是一個獨立的協議，不只有 HTTP 可以使用，其他應用層協議也可以使用，比如FTP、SMTP都可以使用SSL來加密。
7.2 HTTPS請求流程
HTTPS請求全流程如下圖：
如上圖所示：
- 1）用戶在瀏覽器發起HTTPS請求，默認使用服務端的443端口進行連接；
- 2）HTTPS需要使用一套CA 數字證書，證書內會附帶一個服務器的公鑰Pub，而與之對應的私鑰Private保留在服務端不公開；
- 3）服務端收到請求，返回配置好的包含公鑰Pub的證書給客戶端；
- 4）客戶端收到證書，校驗合法性，主要包括是否在有效期內、證書的域名與請求的域名是否匹配，上一級證書是否有效（遞歸判斷，直到判斷到系統內置或瀏覽器配置好的根證書），如果不通過，則顯示HTTPS警告信息，如果通過則繼續；
- 5）客戶端生成一個用于對稱加密的隨機Key，并用證書內的公鑰Pub進行加密，發送給服務端；
- 6）服務端收到隨機Key的密文，使用與公鑰Pub配對的私鑰Private進行解密，得到客戶端真正想發送的隨機Key；
- 7）服務端使用客戶端發送過來的隨機Key對要傳輸的HTTP數據進行對稱加密，將密文返回客戶端；
- 8）客戶端使用隨機Key對稱解密密文，得到HTTP數據明文；
- 9）后續HTTPS請求使用之前交換好的隨機Key進行對稱加解密。
7.3 HTTPS到底解決了什么問題
HTTPS確實解決了HTTP的三個安全性問題：
- 1） 保密性：結合非對稱加密和對稱加密實現保密性。用非對稱加密方式加密對稱加密的秘鑰，再用對稱加密方式加密數據；
- 2） 完整性：通過第三方CA的數字簽名解決完整性問題；
- 3） 身份校驗：通過第三方CA的數字證書驗證服務器的身份。
7.4 HTTPS優缺點
最后我們總結一下HTTPS的優缺點：
可以看到：HTTPS的確是當今安全傳輸HTTP的最優解，但他并不是完美的，仍會有漏洞。
8、參考資料
[1] 深入淺出，全面理解HTTP協議
[2] HTTP協議必知必會的一些知識
[3] 從數據傳輸層深度解密HTTP
[4] 一文讀懂HTTP協議的歷史演變和設計思路
[5] 你知道一個TCP連接上能發起多少個HTTP請求嗎？
[6] 如果這樣來理解HTTPS，一篇就夠了
[7] 一分鐘理解 HTTPS 到底解決了什么問題
[8] 你知道，HTTPS用的是對稱加密還是非對稱加密？
[9] HTTPS時代已來，打算更新你的HTTP服務了嗎？
[10] 一篇讀懂HTTPS：加密原理、安全邏輯、數字證書等
[11] 全面了解移動端DNS域名劫持等雜癥：原理、根源、HttpDNS解決方案等
（本文已同步發布于：http://www.52im.net/thread-3897-1-1.html）