Off-Topic Discussion: Detectability of ShadowTLS v1

[gaukas]

Hi @3andne, decent work on Restls, the design looks promising and I'd love to give it a deeper look.

This could be off-topic and outdated, possibly should be put in Discussion instead of Issues. Please feel free to close the issue if you are not interested.

Our paper has been accepted by Free and Open Communications on the Internet FOCI'23: Chasing Shadows: A security analysis of the ShadowTLS proxy. The paper is revealing attacks that could effectively identify a ShadowTLS v1 server setup. Some of the mentioned problems were fixed in v2 but not all of them. You may want to pay extra attention to these vulnerabilities when implementing a TLS/FakeTLS server. It is a shame we couldn't make it public earlier due to the anonymity issue.

I will be willing to discuss more on detection vulnerabilities.

Thanks.

[CoiaPrant233]

作为开发商业程序的人，我不方便透露那些，以便和其他人竞争。不过有一些微乎其微的问题，我可以提一下。

[CoiaPrant233]

比如说呢

deb.debian.org 的解析 都是Fastly的 那个ASN查一下就可以，这算是一个问题 选sni要谨慎

我们不能确定中间人是否拥有sni与ip/asn的对照表

[CoiaPrant233]

其次端口应该强制到443上，不在443上的TLS伪装成cdn 太假

[RPRX]

我说一下你的方案，首先，你用别人的证书，和 REALITY 相比，最大的问题就是你有被 MitM 攻击的风险。手机内置根证书，或者 CA 作恶， 或者目标网站帮衬，内部传输的一切内容相当于明文，就像 SS 没有前向保密性一样：没有前向保密性，无异于明文裸奔。其次，若你的方案在遭到 MitM 时客户端响应不可控，那问题就更大了。

[CoiaPrant233]

我说一下你的方案，首先，你用别人的证书，和 REALITY 相比，最大的问题就是你有被 MitM 攻击的风险。手机内置根证书，或者 CA 作恶， 或者目标网站帮衬，内部传输的一切内容相当于明文，就像 SS 没有前向保密性一样：没有前向保密性，无异于明文裸奔。其次，若你的方案在遭到 MitM 时客户端响应不可控，~那问题就更大了~。

这点已经想到了，我拥有他的证书，我可以直接用来加密，那么我就可以在应用层，比如说HTTP加一个Cookie或者Basic Auth的头来认证，如果被重定向攻击了，服务器也只会返回常规的HTTP Response。如果中间人可以拿到证书的话，那么中间人只需要尝试解密你们的TLS包内容，不管是Shadow TLS也好，restls也好，或者你的REALITY协议也好。如果手机根证书都不安全了，那么谁又能保证他不会在进入代理客户端之前就劫持流量呢

[RPRX]

选sni要谨慎

关于这个问题，我的建议是选和目标机房 IP 相近的，延迟也更真实些，但是我说了，若有 TLS session，这个三体问题无法解决。

其次端口应该强制到443上，不在443上的TLS伪装成cdn 太假

真的是会谢，正常人都会首选 443 端口，此外，80 等其它端口，UDP 443 什么的也要转发。

[CoiaPrant233]

我觉得这点虽然有可能，但是不切实际。如果证书被中间盒已经拿到了，你们的协议握手也不会完成。

[CoiaPrant233]

选sni要谨慎

关于这个问题，我的建议是选和目标机房 IP 相近的，延迟也更真实些，但是我说了，若有 TLS session，这个三体问题无法解决。

其次端口应该强制到443上，不在443上的TLS伪装成cdn 太假

~真的是会谢~，正常人都会首选 443 端口，此外，80 等其它端口，UDP 443 什么的也要转发。

是的，我确实要说这点，要装的像，之前没有人提过。

[CoiaPrant233]

~我其实还有一个迫害论~

~正常https连接对外连接都会先请求一次DNS，如果被监控了发现没有请求dns或者dns返回何实际连接不符，也会露馅~

当然不太现实

[CoiaPrant233]

选sni要谨慎

关于这个问题，我的建议是选和目标机房 IP 相近的，延迟也更真实些，但是我说了，若有 TLS session，这个三体问题无法解决。

其次端口应该强制到443上，不在443上的TLS伪装成cdn 太假

~真的是会谢~，正常人都会首选 443 端口，此外，80 等其它端口，UDP 443 什么的也要转发。

最好给Failback加一个限速，不然有可能会被别人扫去当加速用。

[RPRX]

这点已经想到了，我拥有他的证书，我可以直接用来加密，那么我就可以在应用层，比如说HTTP加一个Cookie或者Basic Auth的头来认证，如果被重定向攻击了，服务器也只会返回常规的HTTP Response。如果中间人可以拿到证书的话，那么中间人只需要尝试解密你们的TLS包内容，不管是Shadow TLS也好，restls也好，或者你的REALITY协议也好。如果手机根证书都不安全了，那么谁又能保证他不会在进入代理客户端之前就劫持流量呢

不一样，手机根证书可以预先放置，云服务可以导致所有节点信息泄露，这些并不需要 GFW 有对手机的实时控制权。

而 REALITY 的设计就是在默认终端设备，比如手机已经处于这种根证书有鬼、节点信息泄露的前提下，保障传输内容的私密性。

我觉得这点虽然有可能，但是不切实际。如果证书被中间盒已经拿到了，你们的协议握手也不会完成。

我说了：你对 REALITY 的目标理解错了，而这种错误理解，来源于你的视角的低维，与无知。你不知道的是 GFW 识别能力很强，且能拿到节点信息，只是没封，因为他们可以解密 SS 或 DPI 分析出其中的内容，进行监控，这就是 REALITY 要解决的问题。

同样，它也可以进行 MitM attack，目的可以是仅识别，也可以是长期监控。

我大概猜到你是怎么设计的了，我只能说，你的设计甚至无法区分自己是否已经被中间人攻击了。

那么我就可以在应用层，比如说HTTP加一个Cookie或者Basic Auth的头来认证

鉴于你的设计甚至无法区分自己是否已经被中间人攻击了，所以我对此的评价是：远不如 REALITY

如果中间人可以拿到证书的话，那么中间人只需要尝试解密你们的TLS包内容

？TLSv1.3 的证书和加密没有任何关系，就算拿到证书私钥也无法解密流量，这就叫前向保密性，我建议你再去研究研究。

正常https连接对外连接都会先请求一次DNS，如果被监控了发现没有请求dns或者dns返回何实际连接不符，也会露馅

这当然是维度之一，是现实的。

最好给Failback加一个限速，不然有可能会被别人扫去当加速用。

持保留意见。

[CoiaPrant233]

这点已经想到了，我拥有他的证书，我可以直接用来加密，那么我就可以在应用层，比如说HTTP加一个Cookie或者Basic Auth的头来认证，如果被重定向攻击了，服务器也只会返回常规的HTTP Response。如果中间人可以拿到证书的话，那么中间人只需要尝试解密你们的TLS包内容，不管是Shadow TLS也好，restls也好，或者你的REALITY协议也好。如果手机根证书都不安全了，那么谁又能保证他不会在进入代理客户端之前就劫持流量呢

不一样，手机根证书可以预先放置，云服务可以导致所有节点信息泄露，这些并不需要 GFW 有对手机的实时控制权。

而 REALITY 的设计就是在默认终端设备，比如手机已经处于这种根证书有鬼、节点信息泄露的前提下，保障传输内容的私密性。

我觉得这点虽然有可能，但是不切实际。如果证书被中间盒已经拿到了，你们的协议握手也不会完成。

我说了：你对 REALITY 的目标理解错了，而这种错误理解，来源于你的视角的低维，与无知。你不知道的是 GFW 识别能力很强，且能拿到节点信息，只是没封，因为他们可以解密 SS 或 DPI 分析出其中的内容，进行监控，这就是 REALITY 要解决的问题。

同样，它也可以进行 MitM attack，目的可以是仅识别，也可以是长期监控。

我大概猜到你是怎么设计的了，我只能说，你的设计甚至无法区分自己是否已经被中间人攻击了。

那么我就可以在应用层，比如说HTTP加一个Cookie或者Basic Auth的头来认证

鉴于你的设计甚至无法区分自己是否已经被中间人攻击了，所以我对此的评价是：远不如 REALITY

如果中间人可以拿到证书的话，那么中间人只需要尝试解密你们的TLS包内容

？TLSv1.3 的证书和加密没有任何关系，就算拿到证书私钥也无法解密流量，这就叫前向保密性，我建议你再去研究研究。

~正常https连接对外连接都会先请求一次DNS，如果被监控了发现没有请求dns或者dns返回何实际连接不符，也会露馅~

这当然是维度之一，是现实的。

最好给Failback加一个限速，不然有可能会被别人扫去当加速用。

持保留意见。

即使根证书不安全了，我们可以内置自己的根证书，如果设备不安全的话，做再多也没有用的，整个设备处于危险当中，完全可以在流量处理之前就劫持走。有人曾经给我说过电信的光猫会保存流量信息上报，我不能确定他们是否这样子干，我没有亲自发现过。

对于证书来说，中间人可以使用这个证书自己建立一个伪站来分析流量。

[CoiaPrant233]

我知道1.3中证书不参与加密协商，只是验证服务器身份的。

[CoiaPrant233]

交出自己的证书和私钥虽然不现实，但是如果中间人MITM后，真服务器能在ClientHello阶段就发现问题，无法通过签名检查，从而无法解密后续流量。

[CoiaPrant233]

所以我们暂且将其和重定向攻击放到同类

[CoiaPrant233]

如果你有兴趣的话我可以在新协议完成之后和你交流，目前是不打算开源的，~有可能把自己送进去~

[CoiaPrant233]

应用层协商只是用于防止重定向攻击的，对于MITM和重放保护，可以参考Telegram MTProxy FakeTLS的ClientHello认证。只要他无法篡改我的ClientHello，就没办法解密我与代理服务器之间的流量。

双层保护就足够了。

[CoiaPrant233]

我的协议设计甚至不需要服务器在TLS握手中操作数据包

[CoiaPrant233]

我再重复一遍，就事论事，不要带有个人看法。 我不希望在看到类似 远不如 REALITY 的话 否则我们没有什么能聊的。

我可能确实没有你研究的内容多，但是TLS这块我还是比较清楚的。我是一个初中学生，不可能和你一样做到面面俱到，我还有自己的学业和未来。

[LianZiZhou]

It seems inappropriate to discuss here, an IM platform is more appropriate.

[RPRX]

即使根证书不安全了，我们可以内置自己的根证书

你看你这不就开始自相矛盾了？你用的是别人的证书，根本不是自己的根证书签发的，内置自己的根证书有什么用呢？

如果设备不安全的话，做再多也没有用的，整个设备处于危险当中，完全可以在流量处理之前就劫持走。

我说了，安全与否是相对的，对于手机，它可以内置有根证书，且节点会被云同步，但是 GFW 并不能实时控制手机，这是一个真实的问题。所以 REALITY 就是充分考虑这种环境的产物。其它很多协议，包括你的，根本没有考虑到这个问题。

对于证书来说，中间人可以使用这个证书自己建立一个伪站来分析流量。

显然，中间人拿到源证书这种攻击对 REALITY 无效。并且，内置根证书、CA 作恶等攻击对 REALITY 也无效。

我知道1.3中证书不参与加密协商，只是验证服务器身份的。

所以你之前说的拿到证书就能解密是错误的，显然你之前也不知道 X25519 是什么，这也是你一开始能说出“a password”的原因。

交出自己的证书和私钥虽然不现实，但是如果中间人MITM后，真服务器能在ClientHello阶段就发现问题，无法通过签名检查，从而无法解密后续流量。

错。中间人拿可信证书 MitM 的话，真服务器发现不了任何问题。

所以我们暂且将其和重定向攻击放到同类

错。这根本不是同一个问题，不能放到同类。

应用层协商只是用于防止重定向攻击的，对于MITM和重放保护，可以参考Telegram MTProxy FakeTLS的ClientHello认证。只要他无法篡改我的ClientHello，就没办法解密我与代理服务器之间的流量。

你看，这不就出问题了嘛，GFW 来个真实 MitM 却无法解密，这不是异常流量是什么？

当你们还在死扣协议细节的时候，REALITY 早已默认鹦鹉已死，像三体问题一样无解，不如解决一下真实存在的被监控问题。所以虽然 REALITY 可以偷一下别人的 Server Hello，加后续消息 padding 一下什么的多少做做样子（当然，至少比其它方法更优），实际上它更关注在极端条件下实现比常规 TLS 更安全的传输，而这是你们都没有关注到的。我看你很喜欢三体，从维度的角度来说，相比于你们这些二维生物与火鸡的玩具协议，REALITY 是从更高维的视角来关注和解决问题的，是成人玩具，是降维打击。

---

我再重复一遍，就事论事，不要带有个人看法。

我不觉得我带有什么个人看法，反倒是你一开始对我的那些发言真的承包了我一天的笑点，我也一直仅就这些事来评论。

我可能确实没有你研究的内容多，但是TLS这块我还是比较清楚的。

你能承认自己的研究不足，是好事，但我不认为你对 TLS “比较清楚”。

我是一个初中学生，不可能和你一样做到面面俱到，我还有自己的学业和未来。

我是学生，50 包邮

你要明白，我没有想针对谁，我对你的发言，完全是基于你最初针对我的那番狂妄、搞笑发言，否则我真的不想在这里浪费时间。

我的建议是，水平不到，就先多练，不要直接以这么狂的姿态来冲高端局，会很难看。

你不发这段话还好，现在你给我的感觉真的是：我错了，但我是学生我有理。

就像婴儿一样在啼哭，指望博取同情吗？

你再回去看看你最初的一系列发言，况且我并没有 cue 你，是你自己冲上来的，那你一开始不冲不狂不就没这些事？

[RPRX]

@CoiaPrant233

对了，我帮你总结一下你的 弱小和无知，以便你查漏补缺，提升一下自己的姿势水平。由于槽点太多，我只能尽量列举。

1. 首先，你一开始就没看懂 REALITY，没看懂认证部分，没看懂高级的 MitM，更不知道有 padding。 然后一顿瞎**输出，浪费我的时间。显然，你多次提到的“你早就设想过 REALITY”也是不存在的，毕竟你都没看懂。
2. 你甚至不知道 X25519 是什么，那么刺眼的 curve25519.X25519 你都还能说出 “a password”，我替你圆不回来。 当你说出这两个词的时候，就已经暴露了自己的水平，当时我就已经开始看戏了，我很专业的，一般不笑，除非实在忍不住。
3. 不知道 X25519 就算了，我真的没想到你甚至不知道 HKDF 在干什么，描述错一次我算你意外，描述错两次实在圆不回来。 我猜你最多接触到 hmac，毕竟 ShadowTLS 等设计上最多用了这个，现在你明白了，我这里的强度和他们那里是不一样的。
4. 你不知道 AEAD 认证加密，这是由你不知道 HKDF 而暴露的。AES GCM AEAD 字眼全齐，你给我说是 HKDF 干了它们的活。 “至于怎么协商加密的，我并不关心，我只需要大概思路就ok了”......我建议你还是关心一下，免得再闹笑话。
5. X25519、HKDF、AEAD 这些 TLSv1.3 的基石你一概不知，你竟然还能说出“但是TLS这块我还是比较清楚的”？？
6. 所以很多事情就很好理解了：你没看懂 REALITY 是偷别人的 Server Hello 并替换其中的 key_share，是因为你不懂 X25519。
7. 显然你也不知道 TLSv1.3 有方便的零填充 padding，因为你不懂 TLSv1.3。你懂的话，大可直接用它，而不用想其它歪招。 这是标准的一部分，Golang TLS 本来没写这个功能，REALITY 给它加上了，就像加了多个握手消息合并加密功能一样。
8. 你不知道 Ed25519，否则你说不出“源服务器证书比自签名的小”这种话，而且就算人家真证书也是 Ed25519，也会比我们大。 还有，其实自签证书在 REALITY 里就是走个标准流程而已，方便客户端接管证书验证就能判断，不考虑这个的话长度能更短。 我还可以告诉你，dl.google.com 直接把多个握手消息合并加密，这种是最好的，REALITY 仅读到一个长度就可以开干。
9. 你不知道 TLSv1.3 证书仅验身份，否则说不出“如果中间人可以拿到证书的话，那么中间人只需要尝试解密你们的TLS包内容” 其实也很好理解，毕竟密钥交换是 X25519 干的活，而你不知道它是什么，所以你看，一个不知道 X25519 闹出了多少笑话？
10. 显然你也不知道 TLS 标志性的前向保密性，你不知道它是什么，还是因为你能说出上面那句话，加上你不知道 X25519。 你都不知道前向保密性，怎么可能设计得出来？对你的协议还要什么 MitM，就跟 SS 一样，GFW 拿到密码就能长期监控。

就帮你列举十条吧。我没直接给你说 REALITY 服务端真正做了什么，而是让你描述，就是想进一步探一下你的水平，果然一言难尽。可能你对我不熟悉，我偶尔会这么钓鱼，Project X 群里都有印象。幸好我还没发文章，不然就暴露不了你的真实水平了。

如果你感觉到不舒服，那不好意思，一切都是因为你太狂，且不巧狂到我头上了，我忍不住多说几句，让你长长教训，为了你好。

最后送你这位 无知 的 初中生 一句话：

弱小和无知不是生存的障碍，傲慢才是。

[RPRX]

这是谁 marked as abuse 的？是你吗 @3andne

[3andne]

I welcome constructive discussions, but I hope that everyone can maintain mutual respect while doing so. Personal attacks will not be tolerated, so I have hidden inappropriate comments from all participants (not deleted).

[RPRX]

@3andne

尽管你的出发点是好的，但这个做法是欠妥的。

首先，因为 REALITY 没开 issue 区，所以 @CoiaPrant233 发在了这里。你可以看到，我和他之间说的都是 REALITY 的事情，这个 issue 早已实质上变成了一个 REALITY 的 issue，只是恰好在你这里。如果 GitHub 可以跨仓库转 issue，REALITY 会很乐意接收。

其次，人们有获取信息的自由，尽管有些信息观感不佳，任何人仍有权利无障碍地直接阅读它们，你不应该以你的角度来决定哪些信息应该被隐藏，因为它们可能包含重要的信息，却会因为被隐藏而被读者忽视，进而造成误解、误导人们的判断。

基于以上两点，你应当解除对它们的隐藏。

[RPRX]

如果 GitHub 可以跨仓库转 issue

更正：我指的是跨账号/组织转 issue，我想了下，通过临时仓库是可以轻松做到的。

如果你觉得这个 issue 的某些评论在这个仓库内不便展示，我们可以把这个 REALITY 的 issue 转到它的仓库，can we do that？

[ArcCal]

人家都说了是初中生了。初中的孩子能有这种深度已经很难得了。如果真的技术上有认识不够的地方，指出来就是了。 多多指导和鼓励嘛。

[RPRX]

人家都说了是初中生了。初中的孩子能有这种深度已经很难得了。如果真的技术上有认识不够的地方，指出来就是了。 多多指导和鼓励嘛。

这位读者已经被误导了。首先，初中生源于他自己的说法，可信性存疑。其次，他不应该进行那番挑衅发言，这与他的身份无关。 人生而平等，我们没有义务只因挑衅行为来自带有某一身份或标签的个体就对其有更高的容忍度，否则 ta 只会变本加厉。

鉴于部分信息（目前）处于被折叠状态，我必须要提醒各位读者：没有被折叠的信息中存在很多主观叙述与事实错误，而对它们的纠正有一大部分已经被折叠了，需要登录 GitHub 账号、展开后才能查阅。

而对于没有账号或不便登录的读者，你们已经无法查阅这部分内容。 当然，这本不应该发生。

[3andne]

当然，这本不应该发生。

If we all behave ourselves and don't promote personal attacks against each other, there's no need for a moderation effort. You may find a footnote below the comment section, which you agreed upon when you posted your comments, that "Remember, contributions to this repository should follow our GitHub Community Guidelines." I believe being respectful is self-evident.

而对它们的纠正有一大部分已经被折叠了

One thing to keep in mind is that the hidden content is hidden because they directly target other people and abuse them, which by no means is a "correction."

@RPRX @CoiaPrant233 I appreciate the valuable conversation you had. If you believe that the content includes information that should be known by everyone, I'm sure there's a better way to express it. Abusive content, though, is definitely not part of that.

I think it's valid to hold the opinion that disrespectful content is a necessary part of speech. I respect your choice because I treat all of you as adults. My choice then would be to lock this conversation according to the guidelines for now, since the conversation is deemed to be off-topic at this point.