即时消息技术剖析与实战
袁武林
微博研发中心技术专家
24187 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 25 讲
即时消息技术剖析与实战
15
15
1.0x
00:00/00:00
登录|注册

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

私有协议和TLS技术进行防控
多通道方式提升链路可用性
使用HttpDNS绕开运营商的LocalDNS
重置路由器配置
运营商LocalDNS可能导致接入域名的解析被劫持
路由器的DNS设置被篡改
外链爬虫抓取分析
语音转文字和OCR
图片识别技术
敏感词库
端到端加密
使用单向散列算法和盐进行密码加密存储
解决方案
伪造
篡改
截获
中断
防止DNS劫持的方案
DNS劫持问题
联动惩罚处置进行风险识别的后置闭环
内容识别和传播控制的多种手段
采用端到端加密方式提供更加安全的消息传输保护
使用单向散列算法和盐进行密码加密存储
防范DNS劫持的方案和TLS传输层加密协议的应用
访问入口安全和传输链路安全的重要性
内容识别和传播控制
消息内容存储安全
账号密码存储安全
传输链路安全
访问入口安全
消息内容安全性
消息存储安全性
消息传输安全性
消息内容安全性
消息存储安全性
消息传输安全性
安全性作为IM服务的底线和立命之本
消息时序一致性
消息投递的可靠性
消息实时性
小结
消息安全性的三个维度
消息安全性的重要性
HttpDNS和TLS:你的消息聊天真的安全吗?
文章内容
文章主题

该思维导图由 AI 生成,仅供参考

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

消息安全性的三个维度

既然对于即时消息服务来说,安全性是如此的重要和不可妥协,那么到底都有哪些环节可能导致消息安全方面的问题呢?
一般来说,从消息的产生和流转的细分上,我们大概从三个维度来描述消息的安全性:消息传输安全性、消息存储安全性、消息内容安全性。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

即时消息服务安全性是私密社交场景的核心需求。本文从消息传输安全性、消息存储安全性和消息内容安全性三个维度进行了深入探讨。在消息传输安全性方面,作者介绍了HttpDNS技术和TLS协议的重要作用。针对消息存储安全性,文章提到了采用“端到端加密”和“单向散列”算法等方式来保障账号密码和消息内容的安全。对于消息内容的安全性,文章介绍了针对文字内容、图片、视频和链接的识别和处置机制。通过分析即时消息服务中的安全问题和采用的技术方案,本文呈现了即时消息服务安全性的全貌,对关注消息安全的读者具有一定的参考价值。文章提出了一些技术性问题,如TLS是否能识别客户端模拟器仿冒用户真实访问的问题,为读者留下了思考空间。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《即时消息技术剖析与实战》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(27)

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

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

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

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

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

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

    2019-11-28
    4
  • 尔冬橙
    请问如果走localDns,应用层还走http协议么?一般IM消息系统会用到http协议么

    作者回复: httpDNS和是否采用http协议不是强依赖的。IM消息系统里也会大量用到http协议,比如一个图片或者视频,一般是会先通过TCP长连接把这个图片或者视频的ID推到客户端,然后再由端上发起http请求来获取真正的图片和视频。

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

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

    2019-10-31
    1
  • null
    老师,如果需要在服务端存储消息内容,是加密后存储,下推离线消息时,解密之后再推送给用户? 不知道微博消息内容,是使用对称还是非对称加密?

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

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

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

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

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

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

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

    2019-09-10
    1
收起评论
显示
设置
留言
27
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部