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

235 天前
 thisismr2

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

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

现在有第三个人 C

关于对称加密算法 M

问:

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

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

2831 次点击
所在节点    程序员
35 条回复
kera0a
235 天前
C 和 S 没有关系,也就是有没有 C 无所谓

啰啰嗦嗦说了这么多,问题就是 对称加密算法的安全性
Masoud2023
235 天前
4 层转发 TLS 流量是看不到 TLS 流量的细节的
thisismr2
235 天前
/ping @geelaw
waterwave
235 天前
想太多了,可以去搜索研究一下 MITM (中间人攻击)的各种套路。
jstony
235 天前
C 知道 M 和 K ,拿不到消息体。S 知道 M 和消息,拿不到 K 。就 op 给的条件来说,可以认为是安全的,当然是理论上。在实际当中,可能要考虑各种可能性。
ryuutanyou
235 天前
排除 C 的因素,在 M 算法没有被攻破之前,AB 之间通信是安全的。
如果在加上 C 的因素,已经被认定为不安全了,因为密钥 K 已经泄露了。
GeruzoniAnsasu
235 天前
你要从攻击者的角度来看这个问题。

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

从进攻方视角来说,这个体系存在暴露面。(毕竟你只预设 A 和 B 的终端是可信的,S 和 C 没有包含在内)
zhongbiran
235 天前
看了半天,这不就是走 https 的代理嘛
thisismr2
235 天前
@ryuutanyou 感谢回复。但您指的“不安全”仍是主观的,因为 C 只有 K 没有密文。参考 #5
thisismr2
235 天前
@GeruzoniAnsasu 感谢回复。
> K 可由 C 泄露,
是的 C 可以继续泄漏 K 。但文中有一个描述:“C 和 S 没有关系,也就是说他们之间不会(直接或间接的)共享自己知道的东西“。
> 消息可从 S 截获
TLS
> 毕竟你只预设 A 和 B 的终端是可信的,S 和 C 没有包含在内
抱歉。没有描述很清楚。我 append 一条 S 的终端也是安全的。
C 终端自己是自由的,当然注意文中已经描述 任何客户端和 S 都有认证机制 cookie (注册)
geelaw
235 天前
@thisismr2 #3 描述不是很清楚,比如谁是攻击者、攻击者有哪些能力(即达到何种安全性)。
最简单的场景:C 可以把 K 告诉 D ,然后 D 把 K 告诉 S 。
jones2000
235 天前
什么不用两个或更多个 S 点来中转呢? A 把消息拆成 2 或 N 个包( key 也拆成 2 或 N 个) 发给 S1 ,S2 ,然后通过 S1,S2 中转到 B ,然后 B 把包 1 ,包 2 合并,解密。 这样单独的一个 S 点是无法知道完整的 key 和完整的数据包
InkStone
235 天前
你这个假设有点过强了,但在这个假设下它应当确实是安全的。

不过也可以反过来说,一个过强的假设没有现实意义……
wy315700
235 天前
C 和 S 没有关系,也就是说他们之间不会共享自己知道的东西
不代表

C 把 key 告诉了 D ,D 把 key 告诉了 E ,E 把可以告诉了 F 。。。。。最后 R 把 key 告诉了 S ,S 解密 A 和 B 的通讯。
wy315700
235 天前
事实上很多的泄密都是通过这些表面不相干的实体之间的细微联系发生的
matepi
235 天前
这么多信息,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
235 天前
C 啥也不干要他有什么用呢?我要是 C 就直接把密钥公开。
thisismr2
235 天前
@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
235 天前
@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
235 天前
这是考题吗?
这个文字叙述并不严谨,如果抽象出来, 在信息安全这一行是有专门的逻辑形式化验证协议漏洞的。(数学符号逻辑验证),大名鼎鼎的 Needham–Schroeder 协议在使用了 20 多年后漏洞就是这样发现的。

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

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/974750

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX