即時通訊安全篇（十）：IM聊天系統(tǒng)安全手段之通信連接層加密技術(shù)
本文由融云技術(shù)團隊分享，原題“互聯(lián)網(wǎng)通信安全之端到端加密技術(shù)”，內(nèi)容有修訂和改動。
1、引言
隨著移動互聯(lián)網(wǎng)的普及，IM即時通訊類應(yīng)用幾乎替代了傳統(tǒng)運營商的電話、短信等功能。得益于即時通訊技術(shù)的實時性優(yōu)勢，使得人與人之間的溝通和交流突破了空間、時間等等限制，讓信息的傳遞變的無處不在。
但互聯(lián)網(wǎng)為我們的生活帶來極大便利的同時，用戶的隱私和通信安全問題也隨之而來。
對于IM應(yīng)用開發(fā)者來說，信息溝通的開放性也意味著風(fēng)險性，用戶與網(wǎng)絡(luò)和移動設(shè)備的高度依賴，也為不法之徒提供了可乘之機。因此，提升即時通訊應(yīng)用的安全性尤其重要。
本篇文章將圍繞IM通信連接層的安全問題及實現(xiàn)方案，聚焦IM網(wǎng)絡(luò)“鏈路安全”，希望能帶給你啟發(fā)。
學(xué)習(xí)交流：
- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》
- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）
（本文已同步發(fā)布于：http://www.52im.net/thread-4015-1-1.html）
2、系列文章
本文是IM通訊安全知識系列文章中的第10篇，此系列總目錄如下：
《即時通訊安全篇（一）：正確地理解和使用Android端加密算法》
《即時通訊安全篇（二）：探討組合加密算法在IM中的應(yīng)用》
《即時通訊安全篇（三）：常用加解密算法與通訊安全講解》
《即時通訊安全篇（四）：實例分析Android中密鑰硬編碼的風(fēng)險》
《即時通訊安全篇（五）：對稱加密技術(shù)在Android平臺上的應(yīng)用實踐》
《即時通訊安全篇（六）：非對稱加密技術(shù)的原理與應(yīng)用實踐》
《即時通訊安全篇（七）：如果這樣來理解HTTPS原理，一篇就夠了》
《即時通訊安全篇（八）：你知道，HTTPS用的是對稱加密還是非對稱加密？》
《即時通訊安全篇（九）：為什么要用HTTPS？深入淺出，探密短連接的安全性》
《即時通訊安全篇（十）：IM聊天系統(tǒng)安全手段之通信連接層加密技術(shù)》（* 本文）
《即時通訊安全篇（十一）：IM聊天系統(tǒng)安全手段之傳輸內(nèi)容端到端加密技術(shù)》（稍后發(fā)布...）
3、即時通訊面臨的安全問題
1）竊取內(nèi)容：如果在整個即時通訊的通信過程中，其數(shù)據(jù)內(nèi)容是未加密或弱加密的，那么其信息被截獲后就可以直接被讀取出來。
那么，這就會導(dǎo)致用戶數(shù)據(jù)（包括個人隱私數(shù)據(jù)）的泄露，甚至可能危害用戶的財產(chǎn)安全（比如微信這類IM中，紅包、錢包都會涉及財產(chǎn)安全）。如果在辦公場景下，被竊取的還可能是公司商業(yè)機密，那勢必將會造成更大的經(jīng)濟損失。
2）篡改內(nèi)容：如果通信內(nèi)容被截獲后，對其進行修改再發(fā)送，會破壞信息的正確性和完整性（此消息已非彼消息）。
3）偽造內(nèi)容：如果用戶通信憑證（比如token）被竊取或在通信過程中穿插其他信息，就可能為冒用用戶身份騙取與之通信者的信任創(chuàng)造可能，埋下更大的安全隱患。
4）傳播不法內(nèi)容：基于即時通訊系統(tǒng)的消息推送能力，不法分子除了可能傳播涉黃、涉賭、暴恐或危害國家安全的信息外，還可能傳播計算機木馬病毒等，可能帶來的危害范圍將進一步擴大。
4、常用的互聯(lián)網(wǎng)攻擊手段
網(wǎng)絡(luò)通信過程中常見的攻擊手段：
1）移植木馬：過在終端移植木馬，截獲或篡改信息。
2）偽造應(yīng)用：通過偽造 APP 或在 APP 中添加后門等方式，使終端用戶誤以為是正常應(yīng)用進行使用，從而達到其不法目的。
3）網(wǎng)絡(luò)抓包：通過在網(wǎng)絡(luò)設(shè)備上進行抓包，獲取用戶通信內(nèi)容。
4）中間人攻擊：通過劫持 DNS 等手段，使用戶通信連接經(jīng)過攻擊者的設(shè)備，從而達到竊取、篡改等目的。
5）漏洞挖掘：服務(wù)端或終端除了自有的程序以外還包含了各種三方組件或中間件，通過挖掘其上的漏洞，達到不法目的。
從上圖和手段可知，聊天信息從應(yīng)用經(jīng)過網(wǎng)絡(luò)到達服務(wù)端，這期間的任何一個環(huán)節(jié)都有可能被人利用。所以，在“危機四伏”的互聯(lián)網(wǎng)絡(luò)通信中，“安全”必須重視。
5、密碼學(xué)在即時通訊系統(tǒng)中的應(yīng)用
5.1 基本常識
針對前述的安全問題和攻擊手段，將密碼學(xué)應(yīng)用在即時通訊系統(tǒng)連接上，對通信數(shù)據(jù)進行加密就變得尤為重要。
密碼學(xué)解決信息安全的三要素（CIA）即：
1）機密性（Confidentiality）：保證信息不泄露給未經(jīng)授權(quán)的用戶；
2）完整性（Integrity）：保證信息從真實的發(fā)信者傳送到真實的收信者手中，傳送過程中沒有被非法用戶添加、刪除、替換等；
3）可用性（Availability）：保證授權(quán)用戶能對數(shù)據(jù)進行及時可靠的訪問。
以上表述，好像有點繞口，我們換個通俗一點的表述。。。
密碼學(xué)在網(wǎng)絡(luò)通信中的三大作用就是：
1）加密：防止壞人獲取你的數(shù)據(jù)；
2）認證：防止壞人修改了你的數(shù)據(jù)而你卻并沒有發(fā)現(xiàn)；
3）鑒權(quán)：防止壞人假冒你的身份。
除 CIA 外，還有一些屬性也是要求達到的，如可控性（Controllability）和不可否認性（Non-Repudiation）。
5.2 在即時通訊中的應(yīng)用
作為即時通訊中的關(guān)鍵組成，IM即時通訊系統(tǒng)為了實現(xiàn)消息的快速、實時送達，一般需要客戶端與服務(wù)器端建立一條socket長連接，用以快速地將消息送達到客戶端。
通常即時通訊客戶端會以?TCP?或?UDP?的方式與服務(wù)器建立連接，同時某些場景下也會使用 HTTP 的方式從服務(wù)器獲取或提交一些信息。
整個過程中所有的數(shù)據(jù)都需進行加密處理，簡單的數(shù)據(jù)加密和解密過程可以歸納為：發(fā)送方輸入明文 -> 加密 -> 生成密文 -> 傳輸密文 -> 接收方解密 -> 得到明文。
這其中，會涉及：
1）對稱加密算法（詳見《對稱加密技術(shù)在Android平臺上的應(yīng)用實踐》）
2）非對稱加密算法（詳見《非對稱加密技術(shù)的原理與應(yīng)用實踐》）；
3）信息摘要算法（詳見《常用加解密算法與通訊安全講解》）。
這其中，我國也有一套自有的密碼算法（國密算法）：國密算法，即國家商用密碼算法，是由國家密碼管理局認定和公布的密碼算法標準及其應(yīng)用規(guī)范，其中部分密碼算法已經(jīng)成為國際標準。如 SM 商用系列密碼：對稱加密算法 SM4、非對稱加密算法 SM2、信息摘要算法 SM3。
6、通信連接層的會話加密
對于連接層面（鏈路層面）面的加密，應(yīng)最先考慮的是基于 SSL/TLS 協(xié)議進行鏈路加密（比如微信的作法：《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》），這是現(xiàn)代網(wǎng)絡(luò)通信安全的基石。
很多人認為 SSL/TLS 協(xié)議是附加在 HTTP 協(xié)議上的，是 HTTPS 的一部分（詳見《為什么要用HTTPS？深入淺出，探密短連接的安全性》）。
其實這種理解不完全正確，SSL/TLS 是獨立于應(yīng)用層協(xié)議的，高層協(xié)議可以透明地分布在 SSL/TLS 協(xié)議上面。因此基于socket長連接的IM即時消息通訊協(xié)議也可以構(gòu)建在 SSL/TLS 協(xié)議上面。
SSL/TLS 是獨立于應(yīng)用層協(xié)議：
SSL/TLS 可以被簡單地歸納為：利用基于公私鑰體系的非對稱加密算法，傳輸對稱加解密算法的密鑰，并將后續(xù)通訊的數(shù)據(jù)包基于雙方相同的對稱加解密算法和密鑰進行加密并傳輸，從而達到保證數(shù)據(jù)安全通訊的目的。
非對稱加密算法里面的公鑰和私鑰在數(shù)學(xué)上是相關(guān)的，這樣才能用一個加密、用另一個解密。不過，盡管是相關(guān)的，但以現(xiàn)有的數(shù)學(xué)算法，是沒有辦法從一個密鑰算出另一個密鑰。
另外需要著重強調(diào)的是：在系統(tǒng)中不要使用自簽證書，而要使用具備 CA 認證的證書，這樣可以有效的防止中間人攻擊。
7、基于SSL/TLS的通信連接層如何實現(xiàn)會話的快速恢復(fù)
7.1 概述
客戶端和服務(wù)器端建立 SSL/TLS 握手時，需要完成很多步驟：密鑰協(xié)商出會話密鑰、數(shù)字簽名身份驗證、消息驗證碼 MAC 等。
整個握手階段比較耗時的是密鑰協(xié)商，需要密集的 CPU 處理。當(dāng)客戶端和服務(wù)器斷開了本次會話連接，那么它們之前連接時協(xié)商好的會話密鑰就消失了。在下一次客戶端連接服務(wù)器時，便要進行一次新的完整的握手階段。
這似乎沒什么問題，但是當(dāng)系統(tǒng)中某一時間段里有大量的連接請求提交時，就會占用大量服務(wù)器資源，導(dǎo)致網(wǎng)絡(luò)延遲增加。
為了解決上面的問題，TLS/SSL 協(xié)議中提供了會話恢復(fù)的方式，允許客戶端和服務(wù)器端在某次關(guān)閉連接后，下一次客戶端訪問時恢復(fù)上一次的會話連接。
會話恢復(fù)有兩種：
1）一種是基于 Session ID 的恢復(fù)；
2）一種是使用 Session Ticket TLS 擴展。
下面來看看兩種方式的優(yōu)劣。
7.2 基于Session ID的SSL/TLS長連接會話恢復(fù)
一次完整的握手階段結(jié)束后，客戶端和服務(wù)器端都保存有這個 Session ID。
在本次會話關(guān)閉，下一次再次連接時：客戶端在 Client Hello 子消息中附帶這個 Session ID 值，服務(wù)器端接收到請求后，將 Session ID 與自己在 Server Cache 中保存的 Session ID 進行匹配。
如果匹配成功：服務(wù)器端就會恢復(fù)上一次的 TLS 連接，使用之前協(xié)商過的密鑰，不重新進行密鑰協(xié)商，服務(wù)器收到帶 Session ID 的 Client Hello 且匹配成功后，直接發(fā)送 ChangeCipherSpec 子協(xié)議，告訴 TLS 記錄層將連接狀態(tài)切換成可讀和可寫，就完成會話的恢復(fù)。
基于Session ID 會話恢復(fù)原理：
雖然使用 Session ID 進行會話恢復(fù)可以減少耗時的步驟，但由于 Session ID 主要保存在服務(wù)器 Server Cache 中，若再次連接請求時由于負載均衡設(shè)定將請求重定位到了其他服務(wù)器上，此時新的服務(wù)器 Server Cache 中沒有緩存與客戶端匹配的 Session ID，會導(dǎo)致會話無法恢復(fù)無法進行，因此不建議選用??Session ID 方式進行會話恢復(fù)。
7.3 基于SessionTicket的SSL/TLS長連接會話恢復(fù)
一次完整的握手過程后，服務(wù)器端將本次的會話數(shù)據(jù)（會話標識符、證書、密碼套件和主密鑰等）進行加密，加密后生成一個 ticket ，并將 ticket 通過 NewSessionTicket 子消息發(fā)送給客戶端，由客戶端來保存，下一次連接時客戶端就將 ticket 一起發(fā)送給服務(wù)器端，待服務(wù)器端解密校驗無誤后，就可以恢復(fù)上一次會話。
基于SessionTicket 會話恢復(fù)原理：
由于加解密都是在服務(wù)端閉環(huán)進行，多服務(wù)只需要共享密鑰就可以完成此過程，相較于 Session ID 的方式，可以不依賴 Server Cache，因此?SessionTicket 會話恢復(fù)方式更有利于大型分布式系統(tǒng)使用。
8、本文小結(jié)
本文分享了IM即時通訊的通信連接層安全知識和加密技術(shù)等。
并著重強調(diào)了兩方面內(nèi)容。首先，在IM即時通訊系統(tǒng)中使用具備 CA 認證的 SSL/TLS 證書可以保證傳輸安全，防止傳輸過程被監(jiān)聽、防止數(shù)據(jù)被竊取，確認連接的真實性。其次，利用 SessionTicket 快速地進行會話恢復(fù)可以提高整體系統(tǒng)性能，降低連接延時。
本文的下篇《即時通訊安全篇（十一）：IM聊天系統(tǒng)安全手段之傳輸內(nèi)容端到端加密技術(shù)》，將繼續(xù)分享基于IM傳輸內(nèi)容的端到端加密技術(shù)，敬請關(guān)注。
9、參考資料
[1]?TCP/IP詳解?-?第11章·UDP：用戶數(shù)據(jù)報協(xié)議
[2]?TCP/IP詳解?-?第17章·TCP：傳輸控制協(xié)議
[3]?網(wǎng)絡(luò)編程懶人入門(三)：快速理解TCP協(xié)議一篇就夠
[4]?網(wǎng)絡(luò)編程懶人入門(四)：快速理解TCP和UDP的差異
[5]?零基礎(chǔ)IM開發(fā)入門(二)：什么是IM系統(tǒng)的實時性？
[6]?對稱加密技術(shù)在Android平臺上的應(yīng)用實踐
[7]?非對稱加密技術(shù)的原理與應(yīng)用實踐
[8]?常用加解密算法與通訊安全講解
[9]微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解
[10]?為什么要用HTTPS？深入淺出，探密短連接的安全性
[11]?探討組合加密算法在IM中的應(yīng)用
（本文已同步發(fā)布于：http://www.52im.net/thread-4015-1-1.html）
