06 | HttpDNS和TLS：你的消息聊天真的安全吗？
该思维导图由 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-09217
王棕生TLS 能识别客户端模拟器仿冒用户真实访问的问题吗？如果不能有什么其他更好的办法？ 答： TLS 是传输层的加密协议，是用来保证消息传输过程中不被截获、篡改和伪造的，但是无法识别仿冒的真实用户。 客户端模拟器如果像真实用户一样来访问服务端，其实是没有必要去识别的，因为此时模拟器一般是为了帮助真实用户做一些事情，没有恶意行为；如果存在恶意行为，进行识别的办法是通过机器学习的方式进行识别，例如：客户端模拟器会频繁发送消息，针对这一特征，可以对线上访问流量进行甄别。作者回复: 是的，模拟器识别确实可以通过机器学习等方式来识别异常行为。对于严格要求进行人机识别的场景，可以使用手机验证码、高难度的验证码识别、或者类似银行U盾的usb客户端证书认证来解决。
2019-09-1014
东东🎈老师，问个im问题，服务端采用读扩散，比如A用户在群里面撤回了一条消息，B用户离线上线怎么收到这条已经撤回的消息，还有个问题群消息是异步mq入库成功后再推送吗，也就是推送的代码要放到mq里面，插入数据库成功后再推送吗？谢谢作者回复: 1. 撤回这条信令也是写入到离线buffer里的，上线时接收方收到原消息和撤回信令，前者会被后者覆盖。 2. 一般是从mq拿到消息进行入库，入库成功才会下推。
2019-09-1038
L你好，对于账号密码存储那块有个问题，如果每个账号密码拥有一个单独的盐（随机的？）那如何验证登录呢？作者回复: 每个uid登录验证时先获取到各自独立的salt，然后和登录提交的密码进行哈希，将结果和存储的密码密文进行一致性校验，这里salt和存储的密码密文一般都会分开存储。
2019-11-284
尔冬橙请问如果走localDns，应用层还走http协议么？一般IM消息系统会用到http协议么作者回复: httpDNS和是否采用http协议不是强依赖的。IM消息系统里也会大量用到http协议，比如一个图片或者视频，一般是会先通过TCP长连接把这个图片或者视频的ID推到客户端，然后再由端上发起http请求来获取真正的图片和视频。
2020-02-161
龙老师，对消息内容（主要考虑文本），进行加解密的话，综合考虑性能，一般用什么技术来加解密比较好呢？作者回复: 常用的对称加密就可以吧，AES-128 AES-256这些加上随机数。
2019-10-311- null老师，如果需要在服务端存储消息内容，是加密后存储，下推离线消息时，解密之后再推送给用户？ 不知道微博消息内容，是使用对称还是非对称加密？
作者回复: 消息存储的时候不一定需要加密哈，使用tls来进行消息传输基本就能避免消息被中途截获，篡改的问题。
2019-10-031 - Geek_62a1d1老师，问个问题，您上面说的保证传输链路安全（中断、截获、篡改、伪造）是如何去发现这些问题呢？
作者回复: 这个我不是专业哈，一般可以通过端口扫描、数据抓取分析等方法吧，大点的公司会有专门的网络安全部门来定期检查外网暴露的端口和传输的内容。
2019-09-171 
胡波 allenhu老师你好，请问端到端的加密方式，总不可能每一条消息的发送和接收都采用公私钥做加解密吧？是不是也要通过密钥交换算法来协商一个对称密钥？如果这样，因为连接不是直接建立在用户A和用户B之间，他们是如何做密钥交换的？作者回复: 可以生成一个临时的对称秘钥，通过公钥加密后发给对方，来解决非对称加密性能差的问题，对于普通文本，也可以直接用公钥来加密。公钥可以都存放在公认的第三方权威服务器上（比如iMessage的端到端加密公钥就上传到苹果的Apple IDS服务器上），用户能从服务器获取到你的公钥，另外还可以通过GPG 使用去中心化的信任模型，来自行通过多种渠道交换公钥。
2019-09-141
🐾老师节日快乐作者回复: 谢谢，刚看到哈~
2019-09-101
