即时通信 IM 端到端加密真的可以做到吗？

[cxytz01]

想象这么一个场景 client A 、B 都在 NAT 内部，它们需要通信，那么就需要经过 server 进行协商握手。不论后续是否成功进行 p2p ，亦或借助 server 进行转发，server 俨然就是一个中间人的角色，在协商阶段把 A 、B 的密钥全都替换成 server 的。

只有两种种场景是可以端到端加密的：

• 有个公告板，大家都把自己的公钥发布上去，这时候 server 是做不了手脚的。
• 其中之一方在公网，且它的地址被另一方知道，双方直接通信，不借助 server 打洞。

不知道描述得是否正确，请指正。

[krixaar]

了解一下 OMEMO ？

[mokiki]

内网的话可以扫描整个内网 ip 端口来连接，不需要电脑这样的 server 。此时交换机就是中间人，因你没法保证这个交换机不是含有两个网口的电脑。这种情况只有一楼的方法能保证互相信任。

至于 DH 什么的，也需要用安全的通道事先知道对方的公钥，或通过信任第三方获取对方公钥，典型应用就是 CA 证书体系的浏览器。我就不信有人能把电脑和浏览器的证书都删掉还能用 DH 交换出安全密钥。

[rekulas]

@nomagick 密钥交换只是其中一个逻辑啊，光有交换算法也没法通信，都说远了最简单的 https 通信就是一个非常安全的端端通信，在不自黑的情况下目前没办法破解

[urnoob]

可以，思科的 webex 应该是端到端加密的

[iX8NEGGn]

@nomagick 你不会天真认为 DH 算法能防止中间人攻击吧，中间人可以两端都骗，算出两端的密钥，最终解决方案就是和 TLS 一样，引入 CA 才能解决。

[nomagick]

@iX8NEGGn
@mokiki
大哥 DH 自己就这么不堪么，你们是都不用 ssh 登服务器么，ssh 就没 CA ，照这么说没法用了
等下回连新机器人问你相信不相信对方的 key 的时候，回答否然后给机房打电话确认一下？

[akira]

信任都是有基础假设条件的啊。
在 server 不可信的前提下，AB 之间连身份都无法信任了。

[rekulas]

@nomagick 那你仔细想一想，要求你确认的目的是什么？就是为了让你自己负责对方是否可信啊，那么问题来了

如果你没有第三方认证机构，你确认的时候怎么知道对方是否可信呢？如果是假冒的你也无法分别
如果你说你本地存储了一份信任服务器名单，那又有个新问题，信任名单是从哪里来的呢？如果你通过网络传输，那又陷入了中间人攻击的怪圈。如果你是直接提前协商写死的，那么既然都可以提前协商了还用 dh 干什么，直接写死每个服务器通信对应的加密 key 不就完了？所以说光是 dh 是无法解决端端通信的

[dbolo123]

@nomagick ssh 第一次连接是会被攻击的，所以第一次连接会问你是否信任

[dbolo123]

@dbolo123 安全一点的做法可能是，都选否，然后通过其他方式获取对方公钥，配在自己服务器上，再去连

[iX8NEGGn]

@nomagick SSH 推荐的安全登录方式是证书登录，怎么就没 CA 了，密码模式确实没 CA ，但它就是这么的不堪，随时被中间人工具，你能用不代表它安全，只是没人攻击你罢了。

[nomagick]

@iX8NEGGn 你把密钥和证书搞混了，ssh 出现得早，没有 CA

@rekulas 我寻思 CA 就是你那个本地信任服务器名单啊，而且这里面核心就是事先已知，而不是你说的第三方，
CA 证书的后续分发也是通过网络

@dbolo123 我不信 ssh 问你的时候你答了否

而且我发现本帖对 CA 的认知也不够深，CA 和证书不是只管密钥的，它是将密钥和其他信息进行关联，否则毫无意义，而这个关联的过程是需要 CA 自己单独去进行的，比如一般网站的证书是将密钥和域名关联起来，CA 需要单独验证你是不是持有这个域名。

那么在本帖的场景下如果使用 PKI 那 CA 需要签署什么呢？ 基本上是 UserID 或者 Email 之类的东西吧，那 CA 又从何验证密钥的持有者同时是 UserID 或者 Email 的所有者呢？

明白了吧，根本不现实。

这个帖子讨论的是端到端通信，而不是端到端连接，好比完成密钥交换之后使用 Email 收发密文，所以不要把思维局限在 TLS 上。

所以说关键点就是密钥交换，场景和 ssh 非常相似

[rekulas]

@nomagick ca 并不是信任服务器名单，它只是一个授信机构，也就是初始化的时候可能没有任何证书，唯一的共识就是-所有人都信任 ca ，然后进入通信环节，ca 通过各种认证向客户端办法证书，大家都信任，通信才能继续。

ca+密钥交换，可以实现在不可信网络中的可信通信，这正好是 op 的需求，也是 https 的基础原理
回到你的疑问-ssh 就没 CA ，照这么说没法用了
可以用，但是你的通信时在不可信网络中的不可信通信，通信中的任何一个中间设备都可以对你发起攻击

要说主要的漏洞，可能就是 ca 认证环节了，如果认证不够严格可能会被伪造证书，但鉴于其超低概率和高难度基本可以认为是足够安全的，毕竟我们的互联网就运行在这套理论上而且稳定几十年了

[rekulas]

@rekulas 补充一句，其实普通的 ssh 证书登录也是用了 ca 的，只不过 ca 是自己并不被系统信任，所以开始的时候会询问你是否信任。

完全不依赖 ca 呢？也是可以通信的，但是如上仍然是不可信通信

[iX8NEGGn]

@nomagick SSH 三种登录模式：密码，公钥密钥，证书，我没有搞混，是你不了解技术进步了。

[BloodBlade]

ssh 直接回答 yes 是基于对服务器提供商的信任吧，如果提供商在第一次连接就进行中间人攻击，这时候直接回答 yes 不就中招了？

[yhvictor]

关于 ssh 说几句。
使用公钥通信，只要公钥传到了远端服务器上。
即使有中间人应答，中间人也无法解密通信内容。
也就是第一次回答 yes 也无所谓。

@BloodBlade

[yhvictor]

如果区块链可信的话是可行的。
只要登登记 id 和公钥就行。
比如说张三李四登记了。
那么张三一定能发出一条只有李四才能解密的信息。
不过：
李四能不能收到要看网络上让不让传（某墙），或者信息也上链。

[rekulas]

@yhvictor 确实，你说的对，如果提前拷贝了 ssh 公钥，这种情况无法进行中间攻击。但是这又回到了最早的情形-既然都可以通过某种方式将公钥可信的传递到服务器，那么有没有密钥交换都无所谓，端端通信跟 dh 没关系了。这个我是针对 nomagick 的回复说的。

我也是做区块开发的，至于区块链我跟你看法也一样，区块链本身协议无法提供可信保障，现有的区块链其实都存在这个漏洞的，只不过区块链中间人攻击几乎没有什么收益，而且节点多攻击成本也高-有那能力还不如 51 攻击。
公钥加密-解决不可信网络的可信通信(如 https)
私钥加密-解决不可信网络的身份认证(如区块链)

[BloodBlade]

@yhvictor 我的意思是，公钥一般是在购买服务器前先传到云服务提供商，购买服务器后再由提供商写入到服务器上，这个过程中公钥会在提供商中经过一次。如果先开服后上传公钥的话，也要通过密码连接或者提供商的后台来传上去，同样也存在被提供商利用的可能性。