互联网通信安全揭秘系列之「链路安全」
以即时通讯和实时音视频为核心的互联网通信技术深入发展，使得人与人之间的交流突破了空间、时间等限制，让信息无远弗届，让连接随时发生，让沟通丰富多元。
但互联网为我们的生活带来极大便利的同时，用户隐私和通信安全问题也随之而来。
对于开发者来说，互联网的开放性也意味着风险性；用户使用网络和终端设备的高自由度，也为不法之徒提供了可乘之机。
因此，提升互联网通信的安全性需要贯穿系统构建的始终。本系列文章主要围绕互联网通信的安全性进行探讨，首篇聚焦“链路安全”。
互联网通信系统的安全问题及主要攻击手段
互联网通信系统面临的安全问题
1. 窃取内容
如果在整个互联网通信过程中，其通信内容是未加密或弱加密的，那么其信息被截获后就可以直接被读取出来。
这会导致个人隐私泄露，甚至可能危害用户的财产安全。如果在办公场景下，被窃取的可能是公司商业机密，那将会造成更大的经济损失。
2. 篡改内容
如果通信内容被截获后，对其进行修改再发送，会破坏信息的正确性和完整性。
3. 伪造内容
如果用户通信凭证被窃取或在通信过程中穿插其他信息，就可能为冒用用户身份骗取与之通信者的信任创造可能，埋下隐患。
4. 传播不法内容
常用攻击手段
基于即时通信系统的消息推送能力，不法分子除了可能传播涉黄、涉赌、暴恐或危害国家安全的信息外，还可能传播计算机木马病毒等。
1. 移植木马
通过在终端移植木马，截获或篡改信息。
2. 伪造应用
通过伪造 APP 或在 APP 中添加后门等方式，使终端用户误以为是正常应用进行使用，从而达到其不法目的。
3. 网络抓包
通过在网络设备上进行抓包，获取用户通信内容。
4. 中间人攻击
通过劫持 DNS 等手段，使用户通信连接经过攻击者的设备，从而达到窃取、篡改等目的。
5. 漏洞挖掘
服务端或终端除了自有的程序以外还包含了各种三方组件或中间件，通过挖掘其上的漏洞，达到不法目的。
从上图可知，信息从应用经过网络到达服务端，这期间任何一个环节都可能被人利用。所以，在“危机四伏”的互联网中，构建通信系统需要将“安全”视为第一准则，通过多种手段保障通信安全。
密码学在互联网通信系统连接上的应用
针对以上的安全问题和攻击手段，将密码学应用在互联网通信系统连接上，对通信数据进行加密就变得尤为重要。
密码学解决信息安全的三要素（CIA）即：
机密性（Confidentiality）保证信息不泄露给未经授权的用户。
完整性（Integrity）保证信息从真实的发信者传送到真实的收信者手中，传送过程中没有被非法用户添加、删除、替换等。
可用性（Availability）保证授权用户能对数据进行及时可靠的访问。
除 CIA 外，还有一些属性也是要求达到的，如可控性（Controllability）和不可否认性（Non-Repudiation）。
作为互联网通信的关键组成，即时通信系统为了实现消息的快速送达一般需要客户端与服务器端建立一条长连接，用以快速地将消息送达到客户端。
常见的 C/S 模式下客户端会以 TCP 或 UDP 的方式与服务器建立连接，同时某些场景下也会使用 HTTP 的方式从服务器获取或提交一些信息。
整个过程中所有的数据都需要进行加密处理，简单的数据加密可以归纳为：发送方输入明文，加密，生成密文，传输密文，接收方解密，得到明文。
其中会涉及对称加密算法、非对称加密算法、信息摘要算法。我国也提出了一套自有的密码算法——国密算法。
国密算法，即国家商用密码算法，是由国家密码管理局认定和公布的密码算法标准及其应用规范，其中部分密码算法已经成为国际标准。如 SM 商用系列密码：对称加密算法 SM4、非对称加密算法 SM2、信息摘要算法 SM3。
连接会话加密
对于链路层面的加密，应最先考虑的是基于 SSL/TLS 协议进行链路加密，这是现代互联网通信安全的基石。
很多人认为 SSL/TLS 协议是附加在 HTTP 协议上的，是 HTTPS 的一部分。其实这种理解不完全正确，SSL/TLS 是独立于应用层协议，高层协议可以透明地分布在 SSL/TLS 协议上面。因此基于即时通信的长连接的消息通讯协议也可以构建在 SSL/TLS 协议上面。
SSL/TLS 可以被简单地归结为：利用基于公私钥体系的非对称加密算法，传输对称加解密算法的密钥，并将后续通讯的数据包基于双方相同的对称加解密算法和密钥进行加密并传输，从而达到保证数据安全通讯 的目的。
非对称加密算法里面的公钥和私钥在数学上是相关的，这样才能用一个加密，用另一个解密。不过，尽 管是相关的，但以现有的数学算法，又没有办法从一个密钥，算出另一个密钥。
另外需要着重强调的是，在系统中不要使用自签证书，而要使用具备CA 认证的证书，这样可以有效的防止中间人攻击。
会话快速恢复
客户端和服务器端建立 SSL/TLS 握手时，需要完成很多步骤：密钥协商出会话密钥，数字签名身份验证，消息验证码 MAC 等。
整个握手阶段比较耗时的是密钥协商，需要密集的 CPU 处理。当客户端和服务器断开了本次会话连接，那么它们之前连接时协商好的会话密钥就消失了。在下一次客户端连接服务器时，便要进行一次新的完整的握手阶段，这似乎没什么问题，但是当系统中某一时间段里有大量的连接请求提交时，就会占用大量服务器资源，导致网络延迟增加。
为了解决上面的问题，TLS/SSL 协议中提供了会话恢复的方式，允许客户端和服务器端在某次关闭连接后，下一次客户端访问时恢复上一次的会话连接。会话恢复有两种，一种是基于 Session ID 的恢复，一种是使用 Session Ticket TLS 扩展。
1. Session ID 会话恢复
一次完整的握手阶段结束后，客户端和服务器端都保存有这个 Session ID，在本次会话关闭，下一次再次连接时，客户端在 Client Hello 子消息中附带这个 Session ID 值，服务器端接收到请求后，将 Session ID 与自己在 Server Cache 中保存的 Session ID 进行匹配。
如果匹配成功，那么服务器端就会恢复上一次的 TLS 连接，使用之前协商过的密钥，不重新进行密钥协商，服务器收到带 Session ID 的 Client Hello 且匹配成功后，直接发送 ChangeCipherSpec 子协议，告诉 TLS 记录层将连接状态切换成可读和可写，就完成会话的恢复。
虽然使用 Session ID 进行会话恢复可以减少耗时的步骤，但由于 Session ID 主要保存在服务器 Server Cache 中，若再次连接请求时由于负载均衡设定将请求重定位到了其他服务器上，此时新的服务器 Server Cache 中没有缓存与客户端匹配的 Session ID，会导致会话无法恢复无法进行。因此不建议选用 Session ID 方式进行会话恢复。
2. SessionTicket 会话恢复
一次完整的握手过程后，服务器端将本次的会话数据（会话标识符、证书、密码套件和主密钥等）进行加密，加密后生成一个 ticket ，并将 ticket 通过 NewSessionTicket 子消息发送给客户端，由客户端来保存，下一次连接时客户端就将 ticket 一起发送给服务器端，待服务器端解密校验无误后，就可以恢复上一次会话。
由于加解密都是在服务端闭环进行，多服务只需要共享密钥就可以完成此过程，相较于 Session ID 的方式，可以不依赖 Server Cache，因此 SessionTicket 会话恢复方式更有利于大型分布式系统使用。
本文主要分享了两方面内容，首先，在互联网通信系统中使用具备 CA 认证的 SSL/TLS 证书可以保证传输安全，防止传输过程被监听、防止数据被窃取，确认连接的真实性；其次，利用 SessionTicket 快速地进行会话恢复可以提高整体系统性能，降低连接延时。
针对与开发者密切相关的互联网通信安全话题，本系列文章接下来还将从其他方面展开深度分享，请持续关注。
在社交产品花样繁多、玩法创新的当下，融云 IM 即时通讯不仅拥有强大的历史积累优势，同时在新社交形态频出的当下依然引流行业，永葆创新力和生命力。点击下方链接⬇️，快来体验吧～