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

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

1、引言

随着移动互联网的普及,IM即时通讯类应用几乎替代了传统运营商的电话、短信等功能。得益于即时通讯技术的实时性优势,使得人与人之间的沟通和交流突破了空间、时间等等限制,让信息的传递变的无处不在。

但互联网为我们的生活带来极大便利的同时,用户的隐私和通信安全问题也随之而来。

对于IM应用开发者来说,信息沟通的开放性也意味着风险性,用户与网络和移动设备的高度依赖,也为不法之徒提供了可乘之机。因此,提升即时通讯应用的安全性尤其重要。

本篇文章将围绕IM通信连接层的安全问题及实现方案,聚焦IM网络“链路安全”,希望能带给你启发。

(本文已同步发布于: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:传输控制协议

[3] 网络编程懒人入门(三):快速理解TCP协议一篇就够

[4] 网络编程懒人入门(四):快速理解TCP和UDP的差异

[5] 零基础IM开发入门(二):什么是IM系统的实时性?

[6] 对称加密技术在Android平台上的应用实践

[7] 非对称加密技术的原理与应用实践

[8] 常用加解密算法与通讯安全讲解

[9]微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解

[10] 为什么要用HTTPS?深入浅出,探密短连接的安全性

[11] 探讨组合加密算法在IM中的应用

(本文已同步发布于:http://www.52im.net/thread-4015-1-1.html

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,529评论 5 475
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,015评论 2 379
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,409评论 0 335
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,385评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,387评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,466评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,880评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,528评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,727评论 1 295
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,528评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,602评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,302评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,873评论 3 306
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,890评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,132评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,777评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,310评论 2 342

推荐阅读更多精彩内容