本文由ELab技術團隊分享，原題“探祕HTTPS”，有修訂和改動。
1、引言
對於IM開發者來說，IM裡最常用的通訊技術就是Socket長連線和HTTP短連線（通常一個主流im會是這兩種通訊手段的結合）。從通訊安全的角度來說，Socket長連線的安全性，就是基於SSL/TLS加密的TCP協議來實現的（比如微信的mmtls，見《微信新一代通訊安全解決方案：基於TLS1.3的MMTLS詳解》）；而對於HTTP短連線的安全性，也就是HTTPS了。
到底什麼是HTTPS？為什麼要用HTTPS？今天就藉此機會，跟大家一起深入學習一下HTTPS的相關知識，包括HTTP的發展歷程、HTTP遇到的問題、對稱與非對稱加密演算法、數字簽名、第三方證書頒發機構等概念。
學習交流：
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
- 開源IM框架原始碼：https://github.com/JackJiang2...
（本文已同步釋出於：http://www.52im.net/thread-38...）
2、系列文章
本文是IM通訊安全知識系列文章中的第9篇，此係列總目錄如下：
《即時通訊安全篇（一）：正確地理解和使用Android端加密演算法》
《即時通訊安全篇（二）：探討組合加密演算法在IM中的應用》
《即時通訊安全篇（三）：常用加解密演算法與通訊安全講解》
《即時通訊安全篇（四）：例項分析Android中金鑰硬編碼的風險》
《即時通訊安全篇（五）：對稱加密技術在Android平臺上的應用實踐》
《即時通訊安全篇（六）：非對稱加密技術的原理與應用實踐》
《即時通訊安全篇（七）：如果這樣來理解HTTPS原理，一篇就夠了》
《即時通訊安全篇（八）：你知道，HTTPS用的是對稱加密還是非對稱加密？》
《即時通訊安全篇（九）：為什麼要用HTTPS？深入淺出，探密短連線的安全性》（* 本文）
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的請求如下圖所示：
▲ 上圖引用自《深入淺出，全面理解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明文資料的現象。
下圖就是似曾相識的運營商劫持效果圖：
PS：關於運營商劫持問題，可以詳細閱讀《全面瞭解移動端DNS域名劫持等雜症：原理、根源、HttpDNS解決方案等》。
HTTP主要有以下3點安全性問題：
歸納一下就是：
1）資料保密性問題：因為HTTP無狀態，而且又是明文傳輸，所有資料內容都在網路中裸奔，包使用者括身份資訊、支付賬號與密碼。這些敏感資訊極易洩露造成安全隱患；
2）資料完整性問題：HTTP資料包在到達目的主機前會經過很多轉發裝置，每一個裝置節點都可能會篡改或調包資訊，無法驗證資料的完整性；
3）身份校驗問題：有可能遭受中間人攻擊，我們無法驗證通訊的另一方就是我們的目標物件。
因此，為了保證資料傳輸的安全性，必須要對HTTP資料進行加密。
5、常見的加密方式
5.1 基本情況
常見的加密方式分為三種：
1）對稱加密；
2）非對稱加密；
3）數字摘要。
前兩種適合資料傳輸加密，而數字摘要不可逆的特性常被用於數字簽名。
接下來，我們逐一簡要學習一下這三種常見的加密方法。
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運算，將結果與數字簽名作對比，如果一致則可以認為內容沒有收到篡改。
對稱加密和非對稱加密是公鑰加密、私鑰解密， 而數字簽名正好相反——是私鑰加密（簽名）、公鑰解密（驗證），如下圖所示。
限於篇幅，關於數字證書的內容本文就不再贅述，想詳細瞭解的可以閱讀：
1）一文讀懂Https的安全性原理、數字證書、單項認證、雙項認證等；
2）你知道，HTTPS用的是對稱加密還是非對稱加密？；
3）如果這樣來理解HTTPS，一篇就夠了。
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-38...）