-
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
设计一个随机密钥滚动下发机制,实现前向安全、防长期重放、防潜在攻击等 #177
Comments
这个机制和OTA有什么不同吗? |
@dev4u 完全不是同一个东西 |
看起来若要实现这个机制,明文 TCP 代理协议结构只需一处小改动:返回的数据前加一个字节代表新密钥长度,0 代表无新密钥 2021 年了,只用 AEAD 吧
各方面细节问题已经考虑清楚,有空时我将先用 Xray-core 实现它们,进行一些初步的试验 |
如果没什么问题,此方案可以成为 SIP010,作为 SIP004 和 SIP007 的延续。SIP008 可以提供相应的 API 支持。 |
这个 @fortuna 应该会感兴趣,Outline好像也在考虑前向安全的问题。 |
此方案存在几点细节:
|
|
如果我确实需要实现多设备使用的话要如何实现呢?服务端根据密钥来区分Client么? |
是的,需要生成多个初始密钥,如果同端口则需要进行解密尝试,但由于只判断第一个包,所以代价很低 |
多加几个字段是否可以让各实现之间歧义更少?服务端也可以更明确知道具体是什么client在连接。 |
我觉得按照规范,独立密钥足以同时作为认证机制了? |
@Mygod 说出你的想法 |
@QuantumGhost 又来一个 |
我觉得:
|
Implement it with SIP003, that's quite a good idea. |
|
话说回来,若只是为了翻墙,如果你不介意买个域名,XTLS 可能是现阶段更好的选择。 |
事实上后向安全是很难得到保证的,TLS 也做不到这一点,但动态更新的密钥为后向安全提供了基本的可能性,这一点比 TLS 强 |
@RPRX YOMV 另外补充一点,
如果你要解决终端不受信任的问题,这一些变更远远不够(这是一个非常非常困难的问题,如果我是你我就不会在这上面花时间,除非我在攻读相关领域的博士) |
这个问题很难解决,我只是描述了一个尴尬的事实:由于缺乏前向安全,在国产手机上使用现有的 SS 是风险极高的行为 |
就算有密钥协商,系统依然可以记录你协商得到的短期密钥,所以这些方案并不能确保前向安全 我个人认为,如果你不信任你的手机 / 系统,除了更换设备之外并没有其他解决方案 |
注意云备份是定期备份,不是实时监控,就这一点而言,TLS 方案比 SS 方案更安全 |
或者我这么说,假设你一开始是在电脑上使用 SS,此时只要你电脑不丢,就是相对安全的 某一天你想在手机上用 SS,扫个二维码,晚上系统给你云端一下,boom,连你电脑的 SS 也跟着不安全了,甚至包括历史通讯 |
1、SS的设计目的主要是防止识别,并不是保证流量安全性。 2、SS本身虽然无法保证向前安全,但是用户在访问各种网站的时候仍然会受到TLS保护。由于TLS本身具备了向前安全的保障,所以即使SS流量能被解密也不会被随便窥探到流量内容。 题外话: 3、如果终端无法被信任,那么这个终端上发生的一切同样都不应该信任。 4、为不同客户端随机更换密钥的方案我不认为是一个好方案。 |
说一下前向安全:
|
没救了 |
@RPRX 我问跟OTA有什么区别,意思是我认为你这种想法,会为ss的通讯带来了特征和爆破点。 特征不多说了。 引入的爆破点在于,客户端怎么知道,返回的密钥是中间人告诉他的?还是真实服务端告诉他? |
所以,会带来什么特征? 初始密钥由 SSH/TLS 可信通道传输,而新的密钥是 AEAD 解密出来的,又有什么问题? |
首先TCP是流协议,在应用层上不存在包这种概念。不过,不纠结,就当作所谓一个包是N字节的数据块好了。 对于开销的问题下面做个简单的算术题: root@ryzen:~# openssl speed -evp chacha20-poly1305
Doing chacha20-poly1305 for 3s on 16 size blocks: 58503757 chacha20-poly1305's in 3.00s 单核情况下3秒处理了 58503757 个块,也就是大约 19501252 blocks/s 。 从计算结果来看,基于有100个合法终端的情况下,最多只需要 37 MB/S 就能打死我这台Ryzen 3600的服务器。 如果合法的终端越多,处理能力还会更加低下。 我的意见仍然是如果需要保证流量向前安全,请给流量套一层TLS,这样做的代价更低,安全更有保障。 |
答不对题,我描述的方案又不是强制 SS 端口复用。裸 TCP 协议端口复用就是这样的,并不是非复用不可。 |
还有,我仔细看了一下,你描述的方法有明显问题。 按你的数据,即使是 100 用户同端口,AEAD 并发 37 MB/s 大概需要攻击者有 (37*1024^2)/16 = 2,424,832 个公网端口。 |
鉴于上面有几位根本不懂协议设计或工程实践,Reopen 以跟进 SS 后续进展。 |
尤其是这位错误理解后的错误回复带歪了楼,误导了他人的判断。 |
嘛,就当作是这样吧。 反正我的观点已经表达的很清楚了。 |
不好意思,基于错误认知推导出来的是错误的观点。 从我的角度出发,我已经写了 XTLS,无论是安全、隐蔽、性能都远超 SS,现在我只是在设计一个备用方案。 |
There's a very simple way to implement forward-secrecy to Shadowsocks that is mostly backwards-compatible with existing clients (may need minor tweaks). I want to add that mechanism to the Outline VPN. My proposal relies on Online Configs (SIP008) and I mentioned it at #89 (comment). Basically:
You get forward secrecy because the session secret is obtained over HTTP, which guarantees the secrecy. This mechanism has the added benefit to allow the server admin to seamlessly migrate clients to new servers. We are adding online configs to Outline. The shadowsocks-android and shadowsocks-win clients already support online configs. I'm not sure if they fetch on every connection though, and they certainly don't support TTLs. @felixding Thanks for cc'ing me |
I'd like to make a small correction to the initial post of this thread: there are many protocols that use the same port for TCP and UDP, including FTP, SSH, DNS and TLS/QUIC: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml |
In response to @wevsty in #177 (comment): Outline has been using trial decryption to support multiple keys on the same port since 2018: #130 (comment) It is not an issue to try to decrypt for every client, if you optimize it well (time and allocations!), which took significant work on our part. Besides code optimizations, we also keep the keys sorted but most recently used and have an IP -> key map. We've seen multiple servers in production with over 400 keys and less than 0.1ms to find the key for at least 99% of the connections. |
If Outline plans to implement TTLs for SIP008, shadowsocks-windows will add support. |
抱歉我习惯使用中文,让我们先谈论一下这个问题
注意现在 SS 的特征并不仅仅是 TCP、UDP 同端口这么简单,它还无法被识别为任何已知流量,所以使用不同的端口是更好的选择 |
然后我来说一下通过 TLS 更新密钥这个反复被提及的方式 首先,当然可以这么做,最简单的方法就是定期通过 TLS 等可信通道来更新密钥,没有问题 而对于后者,这里是 SS 用户,如果需要 TLS 的参与,即需要在服务器上部署 TLS,那么,有什么理由不直接用基于 TLS 的代理?一个自建用户,为了实现 FS,去服务器上部署个 TLS,却回来用 SS?这显然是不现实的。就国内的情况而言,目前基于 TLS 的代理具有更好的抗封锁性,还在用 SS 有多种原因,比如不想买域名、更方便些,而我描述的方案就是不强依赖 TLS 的实现。 所以说,对于 Outline,以及其他中心化 VPN 提供商,定期刷新密钥可行,但对于国内自建用户,SS、TLS 基本上是二选一。 此外,感兴趣可以了解一下我写的 XTLS,就现有的 Cross-wall 用途而言,它比 SS 更安全、隐蔽,且有更好的性能。 |
You don't need to buy a domain in order to support TLS. You can use a self-signed certificate and share a fingerprint. That's how we do in the Outline Manager. The app manages the server via a REST API over HTTPS. The clients that support online configs would have to support certificate fingerprints or some other validation (e.g. show the cert to the user and ask for confirmation). One thing that makes my proposal more practical is that it's built on top of the protocol. There's no protocol change needed. The modularity and reuse of existing components makes it a lot simpler and more feasible to deploy. |
对于抗审查来说,使用自签证书,或者其它额外的方式来定期更新密钥,广泛应用后很可能会是强特征。 事实上我是在推动一种“配置无感热更新”的机制,即无需通过别的途径,使用过程中就可以自动完成配置更新,非常精巧。 更新的内容可以是临时密钥,以实现前向安全、防重放等潜在攻击(比如几天后将揭露的一种针对服务端的攻击方式可以通过此机制来缓解),也可以是其它的东西,比如 Port,如果你研究过 VMess 协议的话。 更重要的是,这或许是下一代 Shadowsocks 协议可以参考的设计。 |
@RPRX I would love to see evidences of that. Outline uses self-signed certificates and the evidence I have so far says that it's not used to detect servers. Just because something can be done it doesn't mean it's done or will be done. And you gotta take into account the cost and collateral damage:
|
This is an interesting practice. According to my calculations, based on the assumption of 100 keys, if it is running on an average VPS (single core cpu), it only takes about 25 Mbit/s of malicious traffic to cause a CPU bottleneck in the event of a malicious attack. I think my calculations should be close to the theoretical maximum acceptable speed. |
@wevsty You are right about the server being more vulnerable to DoS attacks, however we haven't seen this being a problem in practice. |
Closed. 既然需要改动现有的协议结构,不如从头设计一个全新的方案,更加彻底地解决现有的、潜在的各种问题。 #178 是不需要改动现有协议结构的,同时同样不需要长期的 TLS,现阶段来说是个更合适的方案。 |
作为一个可以被参考的前向安全方案,Reopen. |
Shadowsocks 现有的设计存在一个非常明显的问题:无前向安全。而对于 TLS,非 FS 套件早已被视为不够安全了。
“前向安全”指的是攻击者拿到现有的密钥时无法解密过往的通讯内容,实现前向安全需要依赖动态密钥及可信源。
由于现在的国产安卓系统都有云备份功能,手机上的 SS 密码没有安全保证,它可以被用来解密一切通讯内容。
此外,由于 SS 的加密不依赖于时间戳,防重放只能靠缓存,但缓存并不是无限的,这就导致实质上的 无法防重放。
虽然 VMess 也没有前向安全,但它的头部加密依赖于时间戳,至少做到了防重放(不过,时间戳并不是唯一解)
顺便提一下:Shadowsocks 没有 UoT 结构,各个实现都是 TCP、UDP 同端口,这并不常见,是非常明显的特征。
为了解决现在的一些问题,SS 需要设计一个随机密钥滚动下发机制,以下是我的构想:
通过上述机制可以实现:
限制设备数。可以看到,相对于现有的机制,上述机制并没有明显增加配置复杂度,却大大增强了各方面的安全性。欢迎补充建议。
The text was updated successfully, but these errors were encountered: