-
Notifications
You must be signed in to change notification settings - Fork 535
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shadowsocks AEAD 加密方式设计存在严重漏洞,无法保证通信内容的可靠性 #183
Comments
开发者群成员进行了 注意
|
This is vulnerable because somebody can "fake" the response stream / packets from a known shadowsocks server.
So the key is to prevent replay on the client side. Here are some of my stupid guess about the applications of this vulnerability:
But these vulnerability doesn't seem to affect personal and private users. :P |
@zonyitoo 想象一下引发 TLS 错误从而根据报错长度来判断是代理。以及,SS AEAD 作为一个加密传输层,本应保证回应可靠。 |
What happened to random IV? |
@Mygod Client IV, even random, does not reflect in a server response by any means. While Server IV may be random because it is out of control. Therefore, an arbitrary Shadowsocks stream, either uploading or downloading, could be reused by a MITM as a response stream to another request as long as both of them involve the same Shadowsocks service. |
This issue indicates that the respond stream / packet could be faked. Consider a senario, a client makes 2 independent TCP connections to a server, then a attackers sliently swaps these 2 connections' respond packets to the client. The client won't notice but only find errors from the applications, because the shadowsocks' client can always decrypt the two respond streams successfully. Further application still unknown, but it should be a problem because sslocal doesn't know it is being attacked. |
Random IV should prevent cross session reordering. You should somehow ensure the IV is random.
|
The swapping happens before the client receives the first respond packet from the server. So it is unrelated that whether the IV is random. A correct implementation of server returns a random IV for every independent connection, but the situation described by this issue can still happen. |
Sure. I guess in this case, you could resolve it by Anyway this is a very active adversary, which is not very realistic in most cases. Although we could implement these mitigations |
And then client xor it back? Hmm, that is a rather good idea. But the attacker can still have your client's IV, so he can also make it happens. |
Yeah never mind 😜. We should maybe authenticate client's IV as additional data instead. P.S. Also now that I think about it the IV autoincrements so nothing needs to be done there. Oops. |
I just wonder what kind of MITM attacker will ever use this vulnerability.
Anyway, a fix would be appreciated, but I don't see much priority. |
如果你正在使用 SS 浏览 HTTPS 网页,那么理论上,对调两条 TCP 返回的数据会导致服务端 TLS alert + 断连,这一行为是固定的。 没错,实际上不光是 AEAD,Shadowsocks 协议的 ciphers 都可以被这样操作,所以理论上是一个通用的识别 SS 的方式。
|
TBH, I believe that we have already come to an agreement that the vulnerability this issue described do exists. So all of subsequence discussion should be based on this agreement. It doesn't mean it is not vulnerable while the application of it is still unknown. It may not be fixed quickly without changing the design of shadowsocks' protocol IF we found an effective POC. |
To avoid the short-term replay attacks to the clients, we'd better keep the bloom-filter persistent on the disk. @zonyitoo Can you try implement this in shaowsocks-rust first? The implementation should be straightforward, just make sure we can restore the previous bloom-filter after restarting the client. |
Ok. I will give a try. But the current implementation about "Ping Pong Bloom Filter" can only filter some of the recent IVs / Salts. If we decide to persist this filter, should we use another data structure? On the other hand, persisting the filter couldn't resolve the issue about stream swapping. |
For a client, ping-pong bloom filter should be good enough. Although we call it short-term replay avoidance, it usually takes weeks to flush the filter for a client. Right, swapping cannot be avoided by bloom-filter. As discussed above, swapping avoidance should be low priority issue. |
@madeye I don't think a bloom filter is useful. The attacker could replay some server messages sent to other clients. |
@Mygod You're assuming different clients share the same key? |
Isn't that what shadowsocks supposed to do? |
Okay, you mean the clients connected to the same server port. Yes, you're right. |
So, in response to #183 (comment), instead of continuing the conversation and encouraging new ideas, the organization changed its description in 7fbcd0d to drop mentions of "secure" and "protect". What a shame. |
Any new idea is welcome. In fact we encourage anyone to fork our code and build their own protocols. In the past few years, I have seen many interesting innovations like v2ray, trojan and XTLS. They work pretty well and that's why we even have a plugin called v2ray... I see many good ideas in this issue. Even shadowsocks may not adopt them (what a shame), but forking is still possible. ShadowsocksR and Outline are two good examples. BTW, I dropped the "secure" and "protect" from the project's description, as they are misleading now. I agree that shadowsocks is just an access tool, and should not be used as security layer. |
I think the "original" description of shadowsocks have defined its design goal. |
I almost forgot our original design goal... Let me put it back. |
Many people have discovered the same thing, especially during the Spring Festival this year. |
如果改變Server回包格式、在Client添加相關機制、針對同連接包的IV添加關於密鑰的限制(只是舉例),「雜交」「自交」都能很輕易地解決。 |
不對稱加密並不能取代對稱加密,只能用於增強對稱加密的安全能力。TLS也不得不使用AES-GCM等AEAD加密演算法。同時,不對稱加密也並不意味如TLS一樣工作。 |
每一条消息对应的nonce都不一样,移花接木后,ssserver不是会解密失败吗? |
@Howard0o0 Nonce 是 counting nonce... 建议再看看 spec... |
@DuckSoft |
感谢大佬 |
https://github.com/shadowsocksrr/shadowsocksr/blob/manyuser/shadowsocks/obfsplugin/auth_chain.py#L538 |
Jm2c, why not implement with long running tunnels multiplexing to different connections, N connections local <-> M tunnels <-> N mirror connections remote. In this fashion, you can use any method to authenticate/obfuscate/fake-characteristics, you can combine ecdh with pretending tls, thus no replay attack can ever happen, support one port multiple users naturally, also saved one RTT, that's a lot, if you open tens of browsers tabs at same time (eg, search google with vim-like extensions), not to mentions the timeout due to censorship will greatly decrease since it will be forced to track & analyze already established connection instead of the setup phase. I don't understand, why so serious about the original protocol and stuck with it? For what? Clowwindy might agree with me, or maybe? |
挖个坟 |
a bit of off-topic.
@RPRX how |
either shadowsocks-2022 implements the response authentication with the request-salt attached.
|
这个问题是昨天发现的,本来我只是想先给 Xray-core 的 Shadowsocks 明文结构加个时间戳以彻底解决对服务端的重放问题。
顺便研究了一下 SS AEAD 的安全性,我脑洞比较大,考虑得比较多,比如是否可以造成 对客户端的攻击,简述如下:
info
也相同,且响应的加密完全独立于请求以上“特性”的利用方式太多了,真的很难排列组合完,还是主要说对客户端的攻击:
在不需要密码的情况下,可以随意对客户端接收的数据进行移花接木或重放等操作,使得被代理程序收到的数据没有任何可靠性。
比如将 A、B 两条 TCP 连接返回的数据对调,Shadowsocks AEAD 客户端是无法发现异常的,只会成功解密并传给被代理程序。
一些 SS 实现是全局共用 IV 过滤器,只能在单一客户端且不重启(which is impossible)的前提下防御重放,防不了移花接木。
Shadowsocks 流加密也存在此问题,有兴趣的可以研究一下 SSR 的
auth_chain_*
系列是否也存在此问题。建议先用 VMess AEAD(实际上它有其它问题,但不是这种严重漏洞),最后感谢某个开发者群成员参与讨论与验证。
需要说明,这里主要是描述存在的漏洞,而对漏洞的利用有很多方式,比如 移花接木、重放、自交、杂交 等,欢迎补充测试结果。
The text was updated successfully, but these errors were encountered: