即时消息技术剖析与实战
袁武林
微博研发中心技术专家
立即订阅
6503 人已学习
课程目录
已完结 24 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 搞懂“实时交互”的IM技术,将会有什么新机遇?
免费
基础篇 (8讲)
01 | 架构与特性:一个完整的IM系统是怎样的?
02 | 消息收发架构:为你的App,加上实时通信功能
03 | 轮询与长连接:如何解决消息的实时到达问题?
04 | ACK机制:如何保证消息的可靠投递?
05 | 消息序号生成器:如何保证你的消息不会乱序?
06 | HttpDNS和TLS:你的消息聊天真的安全吗?
07 | 分布式锁和原子性:你看到的未读消息提醒是真的吗?
08 | 智能心跳机制:解决网络的不确定性
场景篇 (4讲)
09 | 分布式一致性:让你的消息支持多终端漫游
10 | 自动智能扩缩容:直播互动场景中峰值流量的应对
11 | 期中实战:动手写一个简易版的IM系统
12 | 服务高可用:保证核心链路稳定性的流控和熔断机制
进阶篇 (10讲)
13 | HTTP Tunnel:复杂网络下消息通道高可用设计的思考
14 | 分片上传:如何让你的图片、音视频消息发送得更快?
15 | CDN加速:如何让你的图片、视频、语音消息浏览播放不卡?
16 | APNs:聊一聊第三方系统级消息通道的事
17 | Cache:多级缓存架构在消息系统中的应用
18 | Docker容器化:说一说IM系统中模块水平扩展的实现
19 | 端到端Trace:消息收发链路的监控体系搭建
20 | 存储和并发:万人群聊系统设计中的几个难点
21 | 期末实战:为你的简约版IM系统,加上功能
22 | 答疑解惑:不同即时消息场景下架构实现上的异同
结束语 (1讲)
结束语 | 真正的高贵,不是优于别人,而是优于过去的自己
即时消息技术剖析与实战
登录|注册

06 | HttpDNS和TLS:你的消息聊天真的安全吗?

袁武林 2019-09-09
你好,我是袁武林。
在开始之前,我们先回顾一下前面几篇的内容。我们陆续讲到了消息实时性、消息投递的可靠性、消息时序一致性在即时系统业务场景中的重要性和难点,以及相应的实现方案。
如果说消息的“实时性”“投递可靠性”“时序一致性”是评价一个即时消息服务可用性和先进性的重要指标;那么另一个重要的特性:安全性,就是一个 IM 服务能否存在的底线和立命之本。
对于依托即时消息技术之上的各种私密聊天 App、轨迹位置服务、远程工控系统等业务,对于安全性的需要远高于一般业务。
毕竟,没有人能接受私密的聊天内容被第三方窥探,实时位置的暴露甚至可能带来人身方面的安全风险,而涉及了重要的远程工控操作,如果操作被截获或者篡改,可能会导致严重的工程事故。
那么今天,我们就来聊一聊 IM 系统中会有哪些常见的安全问题,针对这些不同安全问题,我们分别采用了哪些技术方案来进行应对。限于篇幅,对于每个技术点的具体实现过程,我们不做深入讨论,你只需要了解到具体方案的适用场景就可以了。

消息安全性的三个维度

既然对于即时消息服务来说,安全性是如此的重要和不可妥协,那么到底都有哪些环节可能导致消息安全方面的问题呢?
一般来说,从消息的产生和流转的细分上,我们大概从三个维度来描述消息的安全性:消息传输安全性、消息存储安全性、消息内容安全性。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《即时消息技术剖析与实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(19)

  • 王棕生
    TLS 能识别客户端模拟器仿冒用户真实访问的问题吗?如果不能有什么其他更好的办法?
    答: TLS 是传输层的加密协议,是用来保证消息传输过程中不被截获、篡改和伪造的,但是无法识别仿冒的真实用户。
             客户端模拟器如果像真实用户一样来访问服务端,其实是没有必要去识别的,因为此时模拟器一般是为了帮助真实用户做一些事情,没有恶意行为;如果存在恶意行为,进行识别的办法是通过机器学习的方式进行识别,例如:客户端模拟器会频繁发送消息,针对这一特征,可以对线上访问流量进行甄别。


    作者回复: 是的,模拟器识别确实可以通过机器学习等方式来识别异常行为。对于严格要求进行人机识别的场景,可以使用手机验证码、高难度的验证码识别、或者类似银行U盾的usb客户端证书认证来解决。

    2019-09-10
    4
  • leslie
    消息安全性问题我记得大规模爆发的经典案例应当是当年的QQ尾巴吧?QQ使用近20年,手机端这块可能因为工作相关特性基本不太接触,不过我个人认为其实其一定程度上还是和PC类类似吧。毕竟手机就是一台Mimi的computer.对于老师说的我还是整体谈一下个人的见解吧;
        其实近15年爆发的安全问题无非出自几方面:
         一类是:客户端;主要表现形式1)弱密码 如简单设置数字就OK,结果被人破解了 2)非安全网络环境下上网 如蹭网、网吧上网时中毒 3)链接非安全,QQ尾巴就是经典案例,此三种是最普遍的;
         一类是服务器端: 1)连接数不限:其实这是个问题;造成QPS过高且不能确定是否是本人登录;故而像QQ或者某些在线教育的基本上都有严格的限制 2)网络安全:这个应当算是个老问题,举个例子吧:例如很多人家里东西被偷无非还是自己没有把门锁好、或者用了个最普通的门或者锁;不然为何为了安全现在会用防盗门 3)系统安全:各种补丁和问题爆发时你不注意不去强化,造成出问题。4)实时监控:网络异常、数据包异常时其实就说明有问题了 这就像现在商店商城都用监控一样。
          一个是应用程序:最经典的案例就是SQL注入,其实追其本源无非就是几个因素吧;1)省事完成了再说,没想到结果就被人利用了,其实老师所说的加密我印象里数据库端国内真正开始做是那次事件爆发之后再有的 2)数据传输时的安全性:举个个人觉得比较好的方式吧,消息中间件kafka这块我认为做的就还算不错,3)敏感过滤:其实不只是敏感词、甚至敏感链接吧。
           其实这些年尤其是2000后网络开始普及后:各种问题层出不穷,这也是为何监管越来越严格;DNS之类的其实真正挖下去肯定是有问题的,我们只能尽力避免一些常规问题,做好防患未然;这就像谷歌的 SRE有句很经典的话“没有问题是有问题的特殊形态”。网络这块深聊下去老师的课程就改成网络安全了 。
         谢谢老师的辛勤付出:期待老师的下节课的分享。

    作者回复: 👍

    2019-09-09
    1
    4
  • 东东🎈
    老师,问个im问题,服务端采用读扩散,比如A用户在群里面撤回了一条消息,B用户离线上线怎么收到这条已经撤回的消息,还有个问题群消息是异步mq入库成功后再推送吗,也就是推送的代码要放到mq里面,插入数据库成功后再推送吗?谢谢

    作者回复: 1. 撤回这条信令也是写入到离线buffer里的,上线时接收方收到原消息和撤回信令,前者会被后者覆盖。
    2. 一般是从mq拿到消息进行入库,入库成功才会下推。

    2019-09-10
    1
    3
  • Geek_62a1d1
    老师,问个问题,您上面说的保证传输链路安全(中断、截获、篡改、伪造)是如何去发现这些问题呢?

    作者回复: 这个我不是专业哈,一般可以通过端口扫描、数据抓取分析等方法吧,大点的公司会有专门的网络安全部门来定期检查外网暴露的端口和传输的内容。

    2019-09-17
    1
  • 🐾
    老师节日快乐

    作者回复: 谢谢,刚看到哈~

    2019-09-10
    1
  • L
    你好,对于账号密码存储那块有个问题,如果每个账号密码拥有一个单独的盐(随机的?)那如何验证登录呢?

    作者回复: 每个uid登录验证时先获取到各自独立的salt,然后和登录提交的密码进行哈希,将结果和存储的密码密文进行一致性校验,这里salt和存储的密码密文一般都会分开存储。

    2019-11-28
  • 墨子
    大佬,问一个问题,wns与dns区别

    作者回复: 您这里提到的wns具体是哪个产品?我看腾讯和万网都有叫wns的网络组件。

    2019-11-18
    1
  • 怪物老爷
    讲的真好!
    2019-11-02
  • 老师,对消息内容(主要考虑文本),进行加解密的话,综合考虑性能,一般用什么技术来加解密比较好呢?

    作者回复: 常用的对称加密就可以吧,AES-128 AES-256这些加上随机数。

    2019-10-31
  • wuhaka
    不仅TLS,任何加密措施都不能解决模拟器伪造请求,这个是个无解的问题,本质上客户端安全攻防的问题,解决办法的实质是windows,android,ios等常用平台客户端如何防止反编译破解,常用字符串常量级加密、汇编花指令、反调试、动态加载吐出二进制文件等手段,道高一尺魔高一丈的问题;服务端机器学习识别为辅,核心是客户端反破解问题
    2019-10-30
  • null
    老师,如果需要在服务端存储消息内容,是加密后存储,下推离线消息时,解密之后再推送给用户?
    不知道微博消息内容,是使用对称还是非对称加密?

    作者回复: 消息存储的时候不一定需要加密哈,使用tls来进行消息传输基本就能避免消息被中途截获,篡改的问题。

    2019-10-03
  • 胡波 allenhu
    老师你好,请问端到端的加密方式,总不可能每一条消息的发送和接收都采用公私钥做加解密吧?是不是也要通过密钥交换算法来协商一个对称密钥?如果这样,因为连接不是直接建立在用户A和用户B之间,他们是如何做密钥交换的?

    作者回复: 可以生成一个临时的对称秘钥,通过公钥加密后发给对方,来解决非对称加密性能差的问题,对于普通文本,也可以直接用公钥来加密。公钥可以都存放在公认的第三方权威服务器上(比如iMessage的端到端加密公钥就上传到苹果的Apple IDS服务器上),用户能从服务器获取到你的公钥,另外还可以通过GPG 使用去中心化的信任模型,来自行通过多种渠道交换公钥。

    2019-09-14
  • Leon📷
    老师,问一个客户端认证的问题,服务器怎么鉴定跟自己通讯的是授权的app,而不是其他非法app

    作者回复: 这个好像比较困难吧,比如源代码泄露,重新基于原有代码来打包一个新app,这种通过请求很难鉴定出来呀,不确定是不是有基于app包md5进行校验的哈。个人觉得更多的是需要防止机器模拟人的行为来使用app吧。

    2019-09-11
  • 刘小兔bunny
    本节DNS块的LocalDNS问题和信息安全问题学习起来有些吃力
    2019-09-09
  • tls是保证传输安全,源头有问题,tls无法识别,解决:服务器对客户端进行筛选,短时间对服务器做大量请求,可做限制处理或要求重新登录

    作者回复: 除了限制处理或者重新登录还有其他方式来验证确实是真正的用户在使用还是模拟器在跑吗?

    2019-09-09
    1
  • 一路向北
    我有个疑问,关于HttpDNS。原理我懂,在进行DNS解析时,直接向自建服务器或第三方服务器去请求。但是进行域名解析的过程,是浏览器的行为,不是开发者的行为,我们怎么去控制DNS解析向自己的服务器发请求呢?

    作者回复: httpDNS就是让浏览器或者APP直接请求“从自建服务器接口返回的IP而不是域名”。

    2019-09-09
    4
  • 有铭
    模拟器不是TLS能识别出来的,本质上模拟器就是外挂,还是脱机挂,要想识别外挂,基本都是靠在客户端内置一些隐藏的检测机制,由服务器激发,因为外挂一般都是“够用就好”,不会在内部实现这些机制,所以对这些被激活的机制没有回应的,就可以判断为模拟器了

    作者回复: 如果是源码级的泄露这些内部机制也能获取到了呀。

    2019-09-09
  • 老师,请教一个额外的问题。nio所说的的异步非阻塞是体现在接收请求和处理请求,还是体现在对请求的读写?或者是是指底层调用了epoll?

    作者回复: epoll就是nio的实现呀,nio的异步非阻塞主要是指io过程中,用户进程不需要等待I/O(比如read和write不需要hang住等待),而是直接返回,并通过Reactor模型来实现socket可读写时才唤醒io线程进行读写操作。

    2019-09-09
  • 墙角儿的花
    不让用端到端加密,支持浏览器的话最合适的是json+wss了吧。
    老师,上篇文章我又留了个问题,辛苦老师再看下帮忙答疑
    多谢

    作者回复: 基本上是这样的:浏览器端 wss + json。

    2019-09-09
收起评论
19
返回
顶部