即时通讯安全篇（十）：IM聊天系统安全手段之通信连接层加密技术

Posted on 2022-08-22 11:35 Jack Jiang 阅读(123) 评论(0) 编辑收藏

本文由融云技术团队分享，原题“互联网通信安全之端到端加密技术”，内容有修订和改动。

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 会话恢复原理：