问： A 和 B 通过 S 中转来进行消息传递是否安全

[thisismr2]

有四个角色，A ，B ，S ，C 。

• S 是一个服务器，A 和 B 是两个人
• A 和 S 之间，B 和 S 之间都使用 HTTPS 协议进行通信
• A 和 B 都在服务器认证了，并拿到了服务器下发的认证 cookie （可以理解为注册并认证了身份）

现在 A 和 B 通过 S 中转来进行消息传递，当然会带上 cookie

• A 为了和 B 之间的消息不让第三者（包括 S ）知道，想到一个密钥 K ，然后开车到 B 家，把 K 告诉了 B
• A 和 B ，一方用 K 使用对称加密算法 M 将消息加密后通过 S 中转来传递给对方，对方收到消息后用 K 解密
• S 不知道 K

现在有第三个人 C

• C 去 B 家做客，B 喝多了把 K 告诉了 C
• C 和 S 没有关系，也就是说他们之间不会共享自己知道的东西

关于对称加密算法 M

• A, B, S, C 都知道 A 和 B 在使用 对称加密算法 M
• 并且 M 公认是安全的

问：

到现在，A 和 B 通过 S 中转来进行消息传递是否安全？

（当然暂不考虑 A 和 B 的电脑被攻破了，cookie 泄漏了等终端安全因素）

#7 补充一条 S 终端也是安全的，也就是不会轻易被入侵/攻破/脱库等

背景 #18
结贴 #33

[kera0a]

C 和 S 没有关系，也就是有没有 C 无所谓

啰啰嗦嗦说了这么多，问题就是 对称加密算法的安全性

[Masoud2023]

4 层转发 TLS 流量是看不到 TLS 流量的细节的

[thisismr2]

/ping @geelaw

[waterwave]

想太多了，可以去搜索研究一下 MITM （中间人攻击）的各种套路。

[jstony]

C 知道 M 和 K ，拿不到消息体。S 知道 M 和消息，拿不到 K 。就 op 给的条件来说，可以认为是安全的，当然是理论上。在实际当中，可能要考虑各种可能性。

[ryuutanyou]

排除 C 的因素，在 M 算法没有被攻破之前，AB 之间通信是安全的。
如果在加上 C 的因素，已经被认定为不安全了，因为密钥 K 已经泄露了。

[GeruzoniAnsasu]

你要从攻击者的角度来看这个问题。

K 可由 C 泄露，消息可从 S 截获，这意味着 A 到 B 并未建立起安全的点对点通信，可以通过欺骗或攻陷 C 和 S 来取得完整消息。

从进攻方视角来说，这个体系存在暴露面。（毕竟你只预设 A 和 B 的终端是可信的，S 和 C 没有包含在内）

[zhongbiran]

看了半天，这不就是走 https 的代理嘛

[thisismr2]

@ryuutanyou 感谢回复。但您指的“不安全”仍是主观的，因为 C 只有 K 没有密文。参考 #5

[thisismr2]

@GeruzoniAnsasu 感谢回复。
> K 可由 C 泄露，
是的 C 可以继续泄漏 K 。但文中有一个描述：“C 和 S 没有关系，也就是说他们之间不会（直接或间接的）共享自己知道的东西“。
> 消息可从 S 截获
TLS
> 毕竟你只预设 A 和 B 的终端是可信的，S 和 C 没有包含在内
抱歉。没有描述很清楚。我 append 一条 S 的终端也是安全的。
C 终端自己是自由的，当然注意文中已经描述 任何客户端和 S 都有认证机制 cookie （注册）

[geelaw]

@thisismr2 #3 描述不是很清楚，比如谁是攻击者、攻击者有哪些能力（即达到何种安全性）。
最简单的场景：C 可以把 K 告诉 D ，然后 D 把 K 告诉 S 。

[jones2000]

什么不用两个或更多个 S 点来中转呢？ A 把消息拆成 2 或 N 个包（ key 也拆成 2 或 N 个） 发给 S1 ，S2 ，然后通过 S1,S2 中转到 B ，然后 B 把包 1 ，包 2 合并，解密。 这样单独的一个 S 点是无法知道完整的 key 和完整的数据包

[InkStone]

你这个假设有点过强了，但在这个假设下它应当确实是安全的。

不过也可以反过来说，一个过强的假设没有现实意义……

[wy315700]

C 和 S 没有关系，也就是说他们之间不会共享自己知道的东西
不代表

C 把 key 告诉了 D ，D 把 key 告诉了 E ，E 把可以告诉了 F 。。。。。最后 R 把 key 告诉了 S ，S 解密 A 和 B 的通讯。

[wy315700]

事实上很多的泄密都是通过这些表面不相干的实体之间的细微联系发生的

[matepi]

这么多信息，S 在其中……感觉是出题的干扰选择项嘛

A 和 B 的通信是否安全，现在就归结于拿到了 K 的 C 怎么使用 K 了

如假设：
1 、B 没有告诉 C ，有 S 的存在，C 通过自身能力、也无法获知 C 的存在与对应调用方法，粗且可以认为 A-B 是安全。
2 、B 告诉了 C ，有 S 的存在，但一般来说，S 对于 B 的交互注册，有名为 KS 的 key 存在，对 KS 尽管 B 喝醉了、B 没有 C ，那么粗且可以认为 A-B 安全

另外，以上假设是从 B 对 C 的情况已经透明可知的情况，如果对于 B 并没有把喝醉这件事情记起来、更没有告诉 A 。那么从 A 视角来看，还有 A 认为 A-B 间是否安全的问题。

从严格的安全角度来看，既然 K 已经泄露了，第一时间更换 K ，是比做上述各种假设更为安全的选择。

[leonshaw]

C 啥也不干要他有什么用呢？我要是 C 就直接把密钥公开。

[thisismr2]

@geelaw #11 嗯，对安全性没有定义明确

- A 和 B 之外的第三者（方）可以得到 A 和 B 之间的明文消息
- 或有第三者（方）冒充 A/B 身份 向 B/A 发送消息（当然 S 的认证机制可以保证，因为假设了 cookie 不会泄漏）

@geelaw #11 @wy315700 #14 @leonshaw #17

嗯，这个问题是其实是一个比较简单的加密场景。看来漏洞就是 C 通过多人转告或 [C 公开了 K] ，比如 push 到 github 上。这样 S 就能解密 A 和 B 的密文了

@geelaw 感谢赐教

背景是，在看 WhatsApp 的白皮书 https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf
开始的阶段需要交换公钥，无论是 Diffie–Hellman ，还是 PGP ，在通过中间人交换公钥的时候，都有可能被中间方替换，而这个中间方就是 WhatsApp 的服务端自己。

但才疏学浅，没看十分明白，即 A 和 B 通过 WhatsApp 交换公钥的时候，怎么让 A 和 B 相信自己得到的公钥就是来自 A 和 B ，而不是 WhatsApp 的。[1]

比如 TLS 本身是依赖一个公共的 CA 列表，大家都相信。PGP ，有时依赖一个 https://keys.openpgp.org ，这个有个简单的身份信息认证机制，有时依赖一个慢慢建立起来的信任网络。

基于[1]；同时，WhatsApp 的协议的复杂度也难于让用户（比如抓包）自己审计传输了什么。就在想有没有可能设计一个最简单的 minimal 的 end-end 加密的方案，用户随时可自行审查的，比如用户随时自己抓包就可以验证整个交互内容和逻辑。

谢谢

[GeruzoniAnsasu]

@thisismr2 这样的描述还是有点模糊，由于细节你是没法全部表述清楚的，我也不可能很快地完整理解整个系统的结构，所以没法下确定性的判断。

但总之
1. 预设服务器不可能攻破并不十分可靠，无论是逻辑缺陷还是旁站业务还是侧信道都有可能从中提取信息，相比之下终端反而安全很多，甚至在考虑存在 0day 的情况下通常也需要 1-click 才会发生入侵
2. C 和 S 不需要共享任何信息，作为攻击者，他的做法可以分别获取想要的信息再重建关联。再说了，「 C 泄露的 K 是 S 上的某个通信密钥」这个关联已经很强了
3. TLS 只能保证链路安全，无法保证端点上的安全，除非 S 是一个单纯的流量转发器，不解析 TLS 中的内容，那么信道没有在 S 上落地，可以认为在 S 点上安全，但描述并非这么回事。
4. A 和 B 的认证 cookie 没有没有包含在信道建立的步骤中，因此没有作用，除非你的设计是登录后创建的信息与 AEAD 加密的 key 强关联，那么登录状态能同时保证消息完整且可认证，这样是可以确认消息只能由持有登录状态的人发出/解出的。


我就假设一个攻击手段好了
1. 想办法批量获取全网的 C ，记录在线时间和 K ，记录为 R
2. 在 S 上取得一组 AB 通信记录，查询对应时间区间的 R ，用 R 对应的 K 解密

如果你真的非要假设 S 绝对安全 —— 安全是基于可信的。S 安全意味着 S 可信，那么你其实不用避免 S 得知 K ，因为 S 理应拿着 K 也不会做任何事。

如果你不担保这点，就是在假设 S 存在「主动向 C 获取 K 来解密他自己正在中转的消息的行为」的可能性，这是你系统设计外的非预期行为，如果系统设计要考虑容许这个非预期也就意味着还要容许诸如「 S 中转的消息被泄露」之类的其它非预期。所以我对你「假定 S 安全」的前提持怀疑态度。

[mightybruce]

这是考题吗？
这个文字叙述并不严谨，如果抽象出来， 在信息安全这一行是有专门的逻辑形式化验证协议漏洞的。(数学符号逻辑验证），大名鼎鼎的 Needham–Schroeder 协议在使用了 20 多年后漏洞就是这样发现的。

从本身来看
这种传递明显不够安全。
反复使用同一个 key, 并没有加上一些生成新 key 的机制，不满足安全上的 key freshness ，另外不满足安全中前向安全性和后向安全性。

[mightybruce]

原来题主想钻研网络安全，这个远远不是工程师和程序员所了解的。
你还是问问大学安全方面的教授比较好， 我工作之前在大学是学信息安全的硕士，很多东西已经还给老师了。
这方面入门看一本书 Springer 出的《 Protocols for authentication and key establishment 》

[mightybruce]

不依赖于公密钥体系和可信第三方 CA 的加密可以做到端到端加密，不过是一种更加复杂的加密
基于身份的密码体系（ identity-based encryption)
2001 年，Boneh 和 Franklin 正式给出 IBE 的定义，安全模型，并应用双线性对（ Bilinear Map ）构造了一个安全的 IBE 方案
不过基于 pairings 的 IBC 方案，在实现时往往都有些性能问题，因此 IBC without pairings 也算是近些年研究比较多的课题。
这些可供了解。

[thisismr2]

@mightybruce #22 是的核心问题就是 基于身份的密码学。涉及到贴文的内容就是 基于一个不可信的第三方来交换密钥。所以才质疑 WhatsApp/Signal 作为不可信第三方的，又没有提供其他渠道（比如线下）来确认。

IBE 好像也是需要依赖一个可信第三方 PKS 。

Boneh Franklin 我搜了一下，好像仍存"可疑"，可能如你所说的是 性能问题

[gps949]

感觉有点 TLDR 了

不就是 AB 通过共享密钥在一个信道中通信，在密钥被共享到第三方 C 后，通信是否安全的问题吗？
首先，如果这个信道（等价于 S+协议）是可信的，就没必要共享密钥，因为认为信道不可信不够安全才使用了共享密钥。
那么信道不可信不够安全的情况下，采用一个已被泄露（不可信不够安全）的共享密钥通信，是否安全呢？这个问题应该都有结论吧？

[mightybruce]

IBE 和 PKS 没有一点关系。
公钥设施并不依赖于某一个公司的，你的电脑和手机在出厂的时候就已经植入受信的安全证书。

[thisismr2]

@mightybruce “你的电脑和手机在出厂的时候就已经植入受信的安全证书。” 也算是依赖可信第三方，新增角色了。（ CNNIC)

[TeresaPanda]

A <-=> S <=> B 的流量都是 https(M(Msg, K))，C 拿到 K 没用吧，破不了 https 这一层。

[thisismr2]

@mightybruce #23 #25 更正 PKG https://en.wikipedia.org/wiki/Identity-based_encryption

[Tink]

安全的

[leonshaw]

@thisismr2
如何证明你是你？用 something you know, you have, you are ，是一定要通过可信第三方或者可信信道分发一些信息的。

[gscsnm]

我觉得安全，就是消息无法被泄密，但是有可能被劫持丢弃。

[thisismr2]

@gscsnm 是的，存在消息被 S 丢弃的可能，但因主观原因被丢弃的可能不大，因为 S 无法解密进而审查。客观原因倒是有，比如负载过高，像某些 IM 那样投递后删了，没有 ACK 机制，等

[thisismr2]

@thisismr2 #18

结贴了： https://signal.org/blog/safety-number-updates/

结论：也就是大家在使用 WhatsApp 或 Signal 时，是无法保证如他们宣传般的安全的，除非你和你的朋友再通过其他方式去验证 指纹（也就是上面的这个文章），其他方式必须是 WhatsApp 或 Signal 之外的方式（裁判和运动员不能是同一角色），比如线下或发邮件。

---

声明： [以上结论仅是笔者研究两天的结果，仅供参考，并不代表权威] 。如果你是密码学或相关领域专家，可以阅读 https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf 和 https://signal.org/blog/safety-number-updates/ 以及其他相关 paper ，以得出更权威的结论。

-- END

[vfs]

密码学不都说了： 不要自己设计加密算法嘛。 单纯想要在 A ，B 之间通过 S 安全的传输信息，那就直接 tls 就够用。 确保你正确的配置了 tls 的参数绝对就够用. （ tls1.3 ， 安全的 cipher suite 等）。 自己设计的，经不起推敲

[sBuk]

暂时安全，C 忘了就永远安全