本文由融云技術團隊分享,原題“互聯網通信安全之端到端加密技術”,內容有修訂和改動。
1、引言
隨著移動互聯網的普及,IM即時通訊類應用幾乎替代了傳統運營商的電話、短信等功能。得益于即時通訊技術的實時性優勢,使得人與人之間的溝通和交流突破了空間、時間等等限制,讓信息的傳遞變的無處不在。
但互聯網為我們的生活帶來極大便利的同時,用戶的隱私和通信安全問題也隨之而來。
對于IM應用開發者來說,信息溝通的開放性也意味著風險性,用戶與網絡和移動設備的高度依賴,也為不法之徒提供了可乘之機。因此,提升即時通訊應用的安全性尤其重要。
本篇文章將圍繞IM通信連接層的安全問題及實現方案,聚焦IM網絡“鏈路安全”,希望能帶給你啟發。

學習交流:
- 移動端IM開發入門文章:《新手入門一篇就夠:從零開發移動端IM》
- 開源IM框架源碼:https://github.com/JackJiang2011/MobileIMSDK(備用地址點此)
(本文已同步發布于:http://www.52im.net/thread-4015-1-1.html)
2、系列文章
本文是IM通訊安全知識系列文章中的第10篇,此系列總目錄如下:
- 《即時通訊安全篇(一):正確地理解和使用Android端加密算法》
- 《即時通訊安全篇(二):探討組合加密算法在IM中的應用》
- 《即時通訊安全篇(三):常用加解密算法與通訊安全講解》
- 《即時通訊安全篇(四):實例分析Android中密鑰硬編碼的風險》
- 《即時通訊安全篇(五):對稱加密技術在Android平臺上的應用實踐》
- 《即時通訊安全篇(六):非對稱加密技術的原理與應用實踐》
- 《即時通訊安全篇(七):如果這樣來理解HTTPS原理,一篇就夠了》
- 《即時通訊安全篇(八):你知道,HTTPS用的是對稱加密還是非對稱加密?》
- 《即時通訊安全篇(九):為什么要用HTTPS?深入淺出,探密短連接的安全性》
- 《即時通訊安全篇(十):IM聊天系統安全手段之通信連接層加密技術》(* 本文)
- 《即時通訊安全篇(十一):IM聊天系統安全手段之傳輸內容端到端加密技術》(稍后發布...)
3、即時通訊面臨的安全問題
1)竊取內容:如果在整個即時通訊的通信過程中,其數據內容是未加密或弱加密的,那么其信息被截獲后就可以直接被讀取出來。
那么,這就會導致用戶數據(包括個人隱私數據)的泄露,甚至可能危害用戶的財產安全(比如微信這類IM中,紅包、錢包都會涉及財產安全)。如果在辦公場景下,被竊取的還可能是公司商業機密,那勢必將會造成更大的經濟損失。
2)篡改內容:如果通信內容被截獲后,對其進行修改再發送,會破壞信息的正確性和完整性(此消息已非彼消息)。
3)偽造內容:如果用戶通信憑證(比如token)被竊取或在通信過程中穿插其他信息,就可能為冒用用戶身份騙取與之通信者的信任創造可能,埋下更大的安全隱患。
4)傳播不法內容:基于即時通訊系統的消息推送能力,不法分子除了可能傳播涉黃、涉賭、暴恐或危害國家安全的信息外,還可能傳播計算機木馬病毒等,可能帶來的危害范圍將進一步擴大。
4、常用的互聯網攻擊手段
網絡通信過程中常見的攻擊手段:

1)移植木馬:過在終端移植木馬,截獲或篡改信息。
2)偽造應用:通過偽造 APP 或在 APP 中添加后門等方式,使終端用戶誤以為是正常應用進行使用,從而達到其不法目的。
3)網絡抓包:通過在網絡設備上進行抓包,獲取用戶通信內容。
4)中間人攻擊:通過劫持 DNS 等手段,使用戶通信連接經過攻擊者的設備,從而達到竊取、篡改等目的。
5)漏洞挖掘:服務端或終端除了自有的程序以外還包含了各種三方組件或中間件,通過挖掘其上的漏洞,達到不法目的。
從上圖和手段可知,聊天信息從應用經過網絡到達服務端,這期間的任何一個環節都有可能被人利用。所以,在“危機四伏”的互聯網絡通信中,“安全”必須重視。
5、密碼學在即時通訊系統中的應用
5.1 基本常識
針對前述的安全問題和攻擊手段,將密碼學應用在即時通訊系統連接上,對通信數據進行加密就變得尤為重要。
密碼學解決信息安全的三要素(CIA)即:
- 1)機密性(Confidentiality):保證信息不泄露給未經授權的用戶;
- 2)完整性(Integrity):保證信息從真實的發信者傳送到真實的收信者手中,傳送過程中沒有被非法用戶添加、刪除、替換等;
- 3)可用性(Availability):保證授權用戶能對數據進行及時可靠的訪問。
以上表述,好像有點繞口,我們換個通俗一點的表述。。。
密碼學在網絡通信中的三大作用就是:
- 1)加密:防止壞人獲取你的數據;
- 2)認證:防止壞人修改了你的數據而你卻并沒有發現;
- 3)鑒權:防止壞人假冒你的身份。
除 CIA 外,還有一些屬性也是要求達到的,如可控性(Controllability)和不可否認性(Non-Repudiation)。
5.2 在即時通訊中的應用
作為即時通訊中的關鍵組成,IM即時通訊系統為了實現消息的快速、實時送達,一般需要客戶端與服務器端建立一條socket長連接,用以快速地將消息送達到客戶端。
通常即時通訊客戶端會以 TCP 或 UDP 的方式與服務器建立連接,同時某些場景下也會使用 HTTP 的方式從服務器獲取或提交一些信息。
整個過程中所有的數據都需進行加密處理,簡單的數據加密和解密過程可以歸納為:發送方輸入明文 -> 加密 -> 生成密文 -> 傳輸密文 -> 接收方解密 -> 得到明文。
這其中,會涉及:
- 1)對稱加密算法(詳見《對稱加密技術在Android平臺上的應用實踐》)
- 2)非對稱加密算法(詳見《非對稱加密技術的原理與應用實踐》);
- 3)信息摘要算法(詳見《常用加解密算法與通訊安全講解》)。
這其中,我國也有一套自有的密碼算法(國密算法):國密算法,即國家商用密碼算法,是由國家密碼管理局認定和公布的密碼算法標準及其應用規范,其中部分密碼算法已經成為國際標準。如 SM 商用系列密碼:對稱加密算法 SM4、非對稱加密算法 SM2、信息摘要算法 SM3。
6、通信連接層的會話加密
對于連接層面(鏈路層面)面的加密,應最先考慮的是基于 SSL/TLS 協議進行鏈路加密(比如微信的作法:《微信新一代通信安全解決方案:基于TLS1.3的MMTLS詳解》),這是現代網絡通信安全的基石。
很多人認為 SSL/TLS 協議是附加在 HTTP 協議上的,是 HTTPS 的一部分(詳見《為什么要用HTTPS?深入淺出,探密短連接的安全性》)。
其實這種理解不完全正確,SSL/TLS 是獨立于應用層協議的,高層協議可以透明地分布在 SSL/TLS 協議上面。因此基于socket長連接的IM即時消息通訊協議也可以構建在 SSL/TLS 協議上面。
SSL/TLS 是獨立于應用層協議:

SSL/TLS 可以被簡單地歸納為:利用基于公私鑰體系的非對稱加密算法,傳輸對稱加解密算法的密鑰,并將后續通訊的數據包基于雙方相同的對稱加解密算法和密鑰進行加密并傳輸,從而達到保證數據安全通訊的目的。
非對稱加密算法里面的公鑰和私鑰在數學上是相關的,這樣才能用一個加密、用另一個解密。不過,盡管是相關的,但以現有的數學算法,是沒有辦法從一個密鑰算出另一個密鑰。
另外需要著重強調的是:在系統中不要使用自簽證書,而要使用具備 CA 認證的證書,這樣可以有效的防止中間人攻擊。
7、基于SSL/TLS的通信連接層如何實現會話的快速恢復
7.1 概述
客戶端和服務器端建立 SSL/TLS 握手時,需要完成很多步驟:密鑰協商出會話密鑰、數字簽名身份驗證、消息驗證碼 MAC 等。
整個握手階段比較耗時的是密鑰協商,需要密集的 CPU 處理。當客戶端和服務器斷開了本次會話連接,那么它們之前連接時協商好的會話密鑰就消失了。在下一次客戶端連接服務器時,便要進行一次新的完整的握手階段。
這似乎沒什么問題,但是當系統中某一時間段里有大量的連接請求提交時,就會占用大量服務器資源,導致網絡延遲增加。
為了解決上面的問題,TLS/SSL 協議中提供了會話恢復的方式,允許客戶端和服務器端在某次關閉連接后,下一次客戶端訪問時恢復上一次的會話連接。
會話恢復有兩種:
- 1)一種是基于 Session ID 的恢復;
- 2)一種是使用 Session Ticket TLS 擴展。
下面來看看兩種方式的優劣。
7.2 基于Session ID的SSL/TLS長連接會話恢復
一次完整的握手階段結束后,客戶端和服務器端都保存有這個 Session ID。
在本次會話關閉,下一次再次連接時:客戶端在 Client Hello 子消息中附帶這個 Session ID 值,服務器端接收到請求后,將 Session ID 與自己在 Server Cache 中保存的 Session ID 進行匹配。
如果匹配成功:服務器端就會恢復上一次的 TLS 連接,使用之前協商過的密鑰,不重新進行密鑰協商,服務器收到帶 Session ID 的 Client Hello 且匹配成功后,直接發送 ChangeCipherSpec 子協議,告訴 TLS 記錄層將連接狀態切換成可讀和可寫,就完成會話的恢復。
基于Session ID 會話恢復原理:

雖然使用 Session ID 進行會話恢復可以減少耗時的步驟,但由于 Session ID 主要保存在服務器 Server Cache 中,若再次連接請求時由于負載均衡設定將請求重定位到了其他服務器上,此時新的服務器 Server Cache 中沒有緩存與客戶端匹配的 Session ID,會導致會話無法恢復無法進行,因此不建議選用 Session ID 方式進行會話恢復。
7.3 基于SessionTicket的SSL/TLS長連接會話恢復
一次完整的握手過程后,服務器端將本次的會話數據(會話標識符、證書、密碼套件和主密鑰等)進行加密,加密后生成一個 ticket ,并將 ticket 通過 NewSessionTicket 子消息發送給客戶端,由客戶端來保存,下一次連接時客戶端就將 ticket 一起發送給服務器端,待服務器端解密校驗無誤后,就可以恢復上一次會話。
基于SessionTicket 會話恢復原理:

由于加解密都是在服務端閉環進行,多服務只需要共享密鑰就可以完成此過程,相較于 Session ID 的方式,可以不依賴 Server Cache,因此 SessionTicket 會話恢復方式更有利于大型分布式系統使用。
8、本文小結
本文分享了IM即時通訊的通信連接層安全知識和加密技術等。
并著重強調了兩方面內容。首先,在IM即時通訊系統中使用具備 CA 認證的 SSL/TLS 證書可以保證傳輸安全,防止傳輸過程被監聽、防止數據被竊取,確認連接的真實性。其次,利用 SessionTicket 快速地進行會話恢復可以提高整體系統性能,降低連接延時。
本文的下篇《即時通訊安全篇(十一):IM聊天系統安全手段之傳輸內容端到端加密技術》,將繼續分享基于IM傳輸內容的端到端加密技術,敬請關注。
9、參考資料
[1] TCP/IP詳解 - 第11章·UDP:用戶數據報協議
[2] TCP/IP詳解 - 第17章·TCP:傳輸控制協議
[4] 網絡編程懶人入門(四):快速理解TCP和UDP的差異
[7] 非對稱加密技術的原理與應用實踐
[8] 常用加解密算法與通訊安全講解
[9]微信新一代通信安全解決方案:基于TLS1.3的MMTLS詳解
[10] 為什么要用HTTPS?深入淺出,探密短連接的安全性
[11] 探討組合加密算法在IM中的應用
(本文已同步發布于:http://www.52im.net/thread-4015-1-1.html)
作者:Jack Jiang (點擊作者姓名進入Github)
出處:http://www.52im.net/space-uid-1.html
交流:歡迎加入即時通訊開發交流群 215891622
討論:http://www.52im.net/
Jack Jiang同時是【原創Java
Swing外觀工程BeautyEye】和【輕量級移動端即時通訊框架MobileIMSDK】的作者,可前往下載交流。
本博文
歡迎轉載,轉載請注明出處(也可前往 我的52im.net 找到我)。