V2ray-core: [Feature Request] 次世代方案：设计一个基于 TLS 的简单协议（VLess）

[cpdyj]

个人认为有极大必要加入 ws/http2 层，否则通讯时序和可能的数据包大小或许会成为另外的特征

[rprx]

个人认为有极大必要加入 ws/http2 层，否则通讯时序和可能的数据包大小或许会成为另外的特征

有必要，供用户选择

[SekiBetu]

胜读十年书，确实如此，大家都在把精力放在创造特征上

[icebluey]

是不是在設計之初就應該考慮支持ESNI ?

[darhwa]

既然基于TLS，何须设计呢？早有现成的h2 tunnel可用。

补丁我早就提交了 #2488 ，issue也开了 #2491 ，一直没有反应。

欢迎各位来试用，反馈。呼声高了，被官方接受的可能性才大。

[rprx]

既然基于TLS，何须设计呢？早有现成的h2 tunnel可用。

补丁我早就提交了 #2488 ，issue也开了 #2491 ，一直没有反应。

欢迎各位来试用，反馈。呼声高了，被官方接受的可能性才大。

1.身份认证等鉴权功能（还有日志什么的？
2.混淆流量以防止基于机器学习的流量分类

不过都不难，直接阉割 VMess 就行

[rprx]

是不是在設計之初就應該考慮支持ESNI ?

ESNI 会在适当的时候由 TLS 实现（指目前 ESNI 非常小众

[ghost]

其它地方的确已经有类似的方案。

[icebluey]

是不是在設計之初就應該考慮支持ESNI ?

ESNI 会在适当的时候由 TLS 实现（指目前 ESNI 非常小众

現在是沒什麼用，只是爲未來正式發布後做準備

[rprx]

是不是在設計之初就應該考慮支持ESNI ?

ESNI 会在适当的时候由 TLS 实现（指目前 ESNI 非常小众

現在是沒什麼用，只是爲未來正式發布後做準備

其实这个是交给 Golang 的 TLS 库来实现的，无需担心不支持

[icebluey]

是不是在設計之初就應該考慮支持ESNI ?

ESNI 会在适当的时候由 TLS 实现（指目前 ESNI 非常小众

現在是沒什麼用，只是爲未來正式發布後做準備

其实这个是交给 Golang 的 TLS 库来实现的，无需担心不支持

重新設計的協議還有必要局限於Golang 嗎？還有必要局限於v2ray 嗎？
還不如另開項目.

[rprx]

重新設計的協議還有必要局限於Golang 嗎？還有必要局限於v2ray 嗎？
還不如另開項目.

关于这一点，我认为v2ray的其它部分还可以一用

重开的话我倾向于rust，以及实现 https://github.com/v2ray/discussion/issues/706
rust还有cloudflare的轮子 https://github.com/cloudflare/quiche

看有没有大佬愿意接手，我还很年轻，并不想花更多时间在这件事上
回复“thumbs down”：如果是因为上面那句话，请尊重个人选择，谢谢

但我向为这个项目和类似项目付出时间的所有人致敬

[p4gefau1t]

既然基于TLS，何须设计呢？早有现成的h2 tunnel可用。
补丁我早就提交了 #2488 ，issue也开了 #2491 ，一直没有反应。
欢迎各位来试用，反馈。呼声高了，被官方接受的可能性才大。

1.身份认证等鉴权功能（还有日志什么的？
2.混淆流量以防止基于机器学习的流量分类

不过都不难，直接阉割 VMess 就行

确实，从vmess精简出鉴权的部分就可以很快实现

TLS以及基于TLS的相关协议应该在近期被优先开发

[darhwa]

身份认证功能，caddy forwardproxy自带。而且还完美防主动探测。

forwardproxy的作者就是uTLS的作者，Sergey Frolov

[rprx]

确实，从vmess精简出鉴权的部分就可以很快实现
TLS以及基于TLS的相关协议应该在近期被优先开发

达成共识。希望标个 Next Label @kslr @vcptr

[darhwa]

@yeahwu 通过v2ray来用，每次请求自动发认证头，就不需要浏览器支持了。

[ActiveIce]

从长远来看，我的观点是
1.外层只使用ws+tls/h2/h3的标准实现，能过CDN为准。
2.内层协议为无状态协议，默认只做鉴权，加密作为可选项。因为有tls保证安全性，此处设计应尽量简单，减少不必要环节，以免产生漏洞或造成性能下降。
3.服务端可以有Nginx，haproxy等做外层的防御并卸载ssl，和一般网站无区别，亦不暴露特征。但客户端是直接通信的，特征是直接暴露的。既然服务端搭建了网站，客户端最好就模拟浏览器。可以参考naiveproxy的方案，采用了chromium的代码。或者将握手明文部分随机化处理。

综上看，最近的解决方法是
简化vmess，只保留鉴权。
只用ws+tls，其他协议仅做个人用途。
随机化或模仿浏览器握手部分明文。

然后再慢慢弄新的

[itshaadi]

someone please translate this thread to english, google translate is the worst.

[icebluey]

try deepl @itshaadi

[klzgrad]

我旗帜鲜明地反对在v2ray里面直接使用TLS。不要因为受了一点挫折，就感觉要拉倒不干了。

v2ray最大的力量不在于它的安全攻防技术在战术上最先进，而在于它起了作用发动群众搞大量土制协议，扩大了安全战略纵深，使得对抗性研究因为目标繁杂而进展困难。

如果所有土制协议都收敛到TLS上，那对抗性研究的范围就大为收窄，难度就大大下降了。所以v2ray协议设计越丑陋，其实就越有韧性。

[SekiBetu]

我旗帜鲜明地反对在v2ray里面直接使用TLS。不要因为受了一点挫折，就感觉要拉倒不干了。

v2ray最大的力量不在于它的安全攻防技术在战术上最先进，而在于它起了作用发动群众搞大量土制协议，扩大了安全战略纵深，使得对抗性研究因为目标繁杂而进展困难。

如果所有土制协议都收敛到TLS上，那对抗性研究的范围就大为收窄，难度就大大下降了。所以v2ray协议设计越丑陋，其实就越有韧性。

这么多年了，也就出了两只手数的清的比较有名的协议，说明大家精力都是有限的，还是得投入到目标明确的数量少的事物当中去，把有限的精力用在刀刃上

[rprx]

我旗帜鲜明地反对在v2ray里面直接使用TLS。不要因为受了一点挫折，就感觉要拉倒不干了。

v2ray最大的力量不在于它的安全攻防技术在战术上最先进，而在于它起了作用发动群众搞大量土制协议，扩大了安全战略纵深，使得对抗性研究因为目标繁杂而进展困难。

如果所有土制协议都收敛到TLS上，那对抗性研究的范围就大为收窄，难度就大大下降了。所以v2ray协议设计越丑陋，其实就越有韧性。

无法认同你的观点：
1.从 SS 到 SSR 再到 VMess，折腾来折腾去，只是“受了一点挫折”？
2.真的“大量”吗？针对“土制协议”的对抗性研究进展困难吗？
3.收敛到 TLS 上，对抗性研究范围的确收窄，但“难度大大下降”？？？
4.“丑陋”指的是更特立独行、特征更明显吗？

不如你跳出思维定式：新土制协议们为什么非要基于纯 TCP 呢？基于 TLS 的百花齐放不是更好吗？

按照目前新土制协议的趋势，TLS 正在取代纯 TCP 成为新的默认底层

不过，如果大佬们时间充裕，不反对同时设计基于纯 TCP 的 VMess 2

[rprx]

从长远来看，我的观点是
1.外层只使用ws+tls/h2/h3的标准实现，能过CDN为准。
2.内层协议为无状态协议，默认只做鉴权，加密作为可选项。因为有tls保证安全性，此处设计应尽量简单，减少不必要环节，以免产生漏洞或造成性能下降。
3.服务端可以有Nginx，haproxy等做外层的防御并卸载ssl，和一般网站无区别，亦不暴露特征。但客户端是直接通信的，特征是直接暴露的。既然服务端搭建了网站，客户端最好就模拟浏览器。可以参考naiveproxy的方案，采用了chromium的代码。或者将握手明文部分随机化处理。

综上看，最近的解决方法是
简化vmess，只保留鉴权。
只用ws+tls，其他协议仅做个人用途。
随机化或模仿浏览器握手部分明文。

然后再慢慢弄新的

基本认同且可行

[hurui200320]

一直在主力使用V2ray，但并不是Go开发者（是个写Java的），想略抒愚见。最近项目中用到了谷歌的GRPC，它是基于Protobuf的，虽然我不太清楚代理底层到底是那种工作机制，但是我想vmess或许可以迁移到GRPC上，这个框架首先支持Go，其次支持TLS认证和加密，可以使用自签CA进行服务器与客户端的双向认证。目前在我手头的项目中表现得不错，但是生成证书和配置上对于非程序员来说可能会比较麻烦，而且如果使用正常网站打掩护，那么自签证书肯定是不太行。但是单方面使用服务器证书认证和加密也完全可以做到，考虑vmess本身也有鉴权，不用双向也行。双向验证在我这儿完全就是因为不想在应用内再做鉴权，所以直接用GRPC提供的机制阻止非认证客户端使用服务。

因为一直没有接触过代理的开发，所以不知道这样的想法行不行。另外关于自制协议，我觉得一个家用路由器都可以轻易的掐断或放行某一种游戏（@华硕）的连接，那GFW对于土制协议我想更是轻而易举。固然数量足够多且不同的土制协议会让GFW看花了眼，但是不排除在这种情况下GFW会选择性的根据流量大小开启类似白名单之类的机制，小额流量可以不管，如果某一个特征的流量达到一定程度，且不认识这种特征，那么就掐断它，我觉得这使得土制协议非常脆弱。就目前来说可能还是混在某种大量且重要的协议中（例如TLS）比较好吧。

[hurui200320]

一直在主力使用V2ray，但并不是Go开发者（是个写Java的），想略抒愚见。最近项目中用到了谷歌的GRPC，它是基于Protobuf的，虽然我不太清楚代理底层到底是那种工作机制，但是我想vmess或许可以迁移到GRPC上，这个框架首先支持Go，其次支持TLS认证和加密，可以使用自签CA进行服务器与客户端的双向认证。目前在我手头的项目中表现得不错，但是生成证书和配置上对于非程序员来说可能会比较麻烦，而且如果使用正常网站打掩护，那么自签证书肯定是不太行。但是单方面使用服务器证书认证和加密也完全可以做到，考虑vmess本身也有鉴权，不用双向也行。双向验证在我这儿完全就是因为不想在应用内再做鉴权，所以直接用GRPC提供的机制阻止非认证客户端使用服务。

因为一直没有接触过代理的开发，所以不知道这样的想法行不行。另外关于自制协议，我觉得一个家用路由器都可以轻易的掐断或放行某一种游戏（@华硕）的连接，那GFW对于土制协议我想更是轻而易举。固然数量足够多且不同的土制协议会让GFW看花了眼，但是不排除在这种情况下GFW会选择性的根据流量大小开启类似白名单之类的机制，小额流量可以不管，如果某一个特征的流量达到一定程度，且不认识这种特征，那么就掐断它，我觉得这使得土制协议非常脆弱。就目前来说可能还是混在某种大量且重要的协议中（例如TLS）比较好吧。

结尾处是指vmess，并不是说不推荐其他代理软件自创协议（微博PTSD）。本质上说一旦失去了多样性，尽管从现实上来说隐藏在大流量中很稳，可一旦要找到突破口，那么没有第二种协议就是一个非常危险的事情。不过怎么说呢，直接基于tcp好像确实有点力不从心吧，要考虑的东西太多了，与GFW背后的人员规模相比，一定是发现的问题总比修复的问题多吧。

[blindwrite]

我旗帜鲜明地反对在v2ray里面直接使用TLS。不要因为受了一点挫折，就感觉要拉倒不干了。
v2ray最大的力量不在于它的安全攻防技术在战术上最先进，而在于它起了作用发动群众搞大量土制协议，扩大了安全战略纵深，使得对抗性研究因为目标繁杂而进展困难。
如果所有土制协议都收敛到TLS上，那对抗性研究的范围就大为收窄，难度就大大下降了。所以v2ray协议设计越丑陋，其实就越有韧性。

无法认同你的观点：
1.从 SS 到 SSR 再到 VMess，折腾来折腾去，只是“受了一点挫折”？
2.真的“大量”吗？针对“土制协议”的对抗性研究进展困难吗？
3.收敛到 TLS 上，对抗性研究范围的确收窄，但“难度大大下降”？？？
4.“丑陋”指的是更特立独行、特征更明显吗？

不如你跳出思维定式：新土制协议们为什么非要基于纯 TCP 呢？基于 TLS 的百花齐放不是更好吗？

按照目前新土制协议的趋势，TLS 正在取代纯 TCP 成为新的默认底层

不过，如果大佬们时间充裕，不反对同时设计基于纯 TCP 的 VMess 2

1. TLS, or any the cryptosystem you can name, has also gone through that period like SS did. For SS, from OTA to AEAD, for now there's no evidence to indicate that AEAD used by SS is insecure, while SS to date is not using TLS.

2. There must be a time gap between the release of one cryptosystem and the date it got cracked. Diversification may not be good on security practice, but it hinders the development of exploit. Think about it, if the protocol is not used by the majority, it deems to have lower resources put into it.

3. If everyone's switching to TLS, there's an implication that the non-TLS traffic will be reduced, and this potentially causes protocol elimination. Starting from the end of last year, we all know that raw TCP traffic got blocked while the WS traffic still works, and this can be a dangerous sign: they're trying to reduce protocol diversification and eventually protocol profiling may be feasible.

4. Don't be picky, he simply means that given the protocol meets the required standards, it's acceptable even if the implementation would be seen as ugly.

5. If you really take a look at the history of cryptosystem, the problem is always on achieving both authentication and integrity at the same time. Are other dimensions like side channel attack a problem? Yes, but that's far behind this one. Why I emphasize this, AEAD itself is not a protocol but a form of encryption that deemed secure if implemented properly. AEAD itself is not a protocol; from this point of view AEAD itself doesn't really have detectable identities; it all lays on the implementation, and if done correctly, it can solve the problem vmess currently faces.

6. (off-topic) In my personal opinion, something you said in this thread is really disgusting and overall didn't really contribute anything, I don't know why people thumb it up given the talk is so empty.

[rprx]

@hurui200320

gRPC 是一种通信机制，同级的有 Restful、GraphQL
ProtoBuf 是一种数据交换格式，同级的有 JSON
TLS 则是底层的可选的安全传输协议/方式

gRPC over ProtoBuf over HTTP/2 over TLS over TCP

其实没必要多一层 ProtoBuf，就像没必要多一层 JSON

[rprx]

@blindwrite

首先，我很高兴你能说出反对的理由，而不只是thumbs down
下面的回复与你的序号一一对应
1.没错，但新问题出现时，SS要手动改进，而不能直接随TLS升级，其实是再造TLS
2.TLS之上也不是不思进取，还要防机器学习流量特征。难道TLS之上就不是hinders the development of exploit吗，只有纯TCP之上才算？跳出思维定式，TLS之上同样可以Diversification
3.他们并没有故意让TLS活下来，而是TLS很棘手，而raw TCP很容易
4.我并不明白他的真实意图，你也不知道
5.我知道AEAD itself is not a protocol but a form of encryption，我也没说不能解决问题，但原因见1。且若根据vmess2的某个提案，我觉得时间不会短。而TLSv1.3已有且只有AEAD
6.请你详细解释一下

另外我想问：我们为了 fq 而设计的这些土制协议，有非基于纯 TCP 不可的原因吗？

有谁能回答上面的问题吗？千万不要因为再造 TLS 入迷而忘了人们最根本的需求。

[tomac4t]

我旗帜鲜明地反对在v2ray里面直接使用TLS。不要因为受了一点挫折，就感觉要拉倒不干了。
v2ray最大的力量不在于它的安全攻防技术在战术上最先进，而在于它起了作用发动群众搞大量土制协议，扩大了安全战略纵深，使得对抗性研究因为目标繁杂而进展困难。
如果所有土制协议都收敛到TLS上，那对抗性研究的范围就大为收窄，难度就大大下降了。所以v2ray协议设计越丑陋，其实就越有韧性。

无法认同你的观点：
1.从 SS 到 SSR 再到 VMess，折腾来折腾去，只是“受了一点挫折”？
2.真的“大量”吗？针对“土制协议”的对抗性研究进展困难吗？

klzgard 说的是纵深防御（Edited: 一个切入点是如果某种协议能被检测到，那么我们仍然有其他许多协议可用），你离题了。

3.收敛到 TLS 上，对抗性研究范围的确收窄，但“难度大大下降”？？？

TLS 指纹问题已经说明这一点了。模仿其他协议终究会因为无法完美模仿而被发现，即鹦鹉已死。

4.“丑陋”指的是更特立独行、特征更明显吗？

不如你跳出思维定式：新土制协议们为什么非要基于纯 TCP 呢？基于 TLS 的百花齐放不是更好吗？

学术界的 Pluggable Transports，从来没有限定于只能是 TLS。​obfs4 就是一个典型的例子。最近进入 alpha 版的 ​SnowFlake 是基于 WebRTC。还有下行速度可以达到 200kb/s 的DNS 隧道 dnstt （使用 Noise Protocol 进行加密）。 “不如你跳出思维定式”，为什么非要基于 TLS 呢？

按照目前新土制协议的趋势，TLS 正在取代纯 TCP 成为新的默认底层

不过，如果大佬们时间充裕，不反对同时设计基于纯 TCP 的 VMess 2

(OT) 我个人也有些 disgusting，主要是因为你有太多断言。不如多看看相关论文吧。

[darhwa]

如果所有土制协议都收敛到TLS上，那对抗性研究的范围就大为收窄，难度就大大下降了。

考虑到大量用户至今仍在使用裸的ss vmess，我觉得事实上不用担心这一点。小(规模)土(法密码学)群(众运动)的主流还是从传输层开始造。坐看众人拾柴火焰高，大寨越办越红火！

[hurui200320]

@hurui200320

gRPC 是一种通信机制，同级的有 Restful、GraphQL
ProtoBuf 是一种数据交换格式，同级的有 JSON
TLS 则是底层的可选的安全传输协议/方式

gRPC over ProtoBuf over HTTP/2 over TLS over TCP

其实没必要多一层 ProtoBuf，就像没必要多一层 JSON

好吧，确实是我肤浅了。我想的是如果使用gRPC进行传输，那么甭管传输什么，如果有特征的话一定是ProtoBuf的特征，这个隔壁Trojan模仿HTTPS差不多。我不太清楚PtotoBuf在防火墙那里占比多少，我觉得如果能与ProtoBuf混在一起，作为远程调用的底层协议，应该是在支持着一些非常重要的服务，按说墙应该不会轻举妄动。但是既然使用TLS和X509证书，那我想（这纯粹是想）未来会不会有朝一日某工信部说所有出国的TLS用的证书一定要经过国内某个CA签名之后才能放行，虽然我觉得实施起来比较困难，但是未来也不能排除吧，就和墙白名单一样，打SS那会儿就说可能，到现在了，也不能彻底排除不可能。

[ActiveIce]

问题不在于如何加密或者如何在TCP上面设计协议，是自制协议在大量的HTTPS流量中是很明显的。设计不仅要满足安全性，还要满足隐匿性。

其实这样看来，服务端和客户端最好是分开设计，毕竟他们行为不同。若客户端使用chrome网络层，服务端隐藏在webserver之后，将会是很完美的方案。至于tls里面包着什么，我相信只要是无状态协议不消耗rtt，不会有什么差别。

[darhwa]

gRPC

他们要套CDN，gRPC就可以直接否决了。gRPC需要h2，起码cloudflare的免费版本是不支持与目标服务器使用h2通信的。

[blindwrite]

@blindwrite

首先，我很高兴你能说出反对的理由，而不只是thumbs down
下面的回复与你的序号一一对应
1.没错，但新问题出现时，SS要手动改进，而不能直接随TLS升级，其实是再造TLS
2.TLS之上也不是不思进取，还要防机器学习流量特征。难道TLS之上就不是hinders the development of exploit吗，只有纯TCP之上才算？跳出思维定式，TLS之上同样可以Diversification
3.他们并没有故意让TLS活下来，而是TLS很棘手，而raw TCP很容易
4.我并不明白他的真实意图，你也不知道
5.我知道AEAD itself is not a protocol but a form of encryption，我也没说不能解决问题，但原因见1。且若根据vmess2的某个提案，我觉得时间不会短。而TLSv1.3已有且只有AEAD
6.请你详细解释一下

1. SS is NOT using TLS, and it's NOT a reimplementation of TLS. The problem is not only on SS but also on the fundamental cryptosystem by that time. If you don't know about the history of AEAD, please go read it before arguing. I don't know why you are so obsess with TLS.

2. I don't think i mentioned TLS? Don't really understand what you mean. But to answer your question: the outermost layer is always the most important, because

   • the inner protocol is infeasible to detect if the outer one has not been dealt with, and
   • given the outer one has been compromised, then it's the problem on the protocol used on the outer layer, not the inter.
     As I said above, other vectors like side channel attack is NOT the prioritized one. What's the point of diversification inside TLS given the outermost is always TLS? Check the history: those severe exploits exist on the outermost layer, ALWAYS.

3. Any prove? I guess that your argument relies on the assumption that TLS is widely used and the firewall cannot block it right now, but that does not really imply anything on security measure. BTW, please don't give arguments that are purely subjective; such arguments will only imply that you're not academic.

4. Please read the context, he said he did not want the diversification to be dampened, which clearly implies what he really meant even if his expression can be misleading.

5. If AEAD can solve the problem, then why must it be TLS? There's too many TLS implementations out there, and what we really need is the diversification, not mimicking another existing project.

6. That's purely subjective view, you can dismiss that.

[stamhe]

我旗帜鲜明地反对在v2ray里面直接使用TLS。不要因为受了一点挫折，就感觉要拉倒不干了。

v2ray最大的力量不在于它的安全攻防技术在战术上最先进，而在于它起了作用发动群众搞大量土制协议，扩大了安全战略纵深，使得对抗性研究因为目标繁杂而进展困难。

如果所有土制协议都收敛到TLS上，那对抗性研究的范围就大为收窄，难度就大大下降了。所以v2ray协议设计越丑陋，其实就越有韧性。

为什么范围就下降？大家都花时间在 tls 上面啊。难道不是更好么？

[rprx]

如果所有土制协议都收敛到TLS上，那对抗性研究的范围就大为收窄，难度就大大下降了。

考虑到大量用户至今仍在使用裸的ss vmess，我觉得事实上不用担心这一点。小(规模)土(法密码学)群(众运动)的主流还是从传输层开始造。坐看众人拾柴火焰高，大寨越办越红火！

用ss的的确不少是裸的，但用vmess的？我不确定。你说的主流是以前的，新时代的主流，参考trojan

[ActiveIce]

关于提到的trojan或其他方案，首先我认为标准的HTTPS流量的实现，一定是能过CDN的(只有trojan-go是可行的)，不然肯定留有不同之处。我不是非常希望v2ray像trojan一样作为一个前端去分辨流量，我希望v2ray还是保持可以被webserver反代的特性，分辨流量或者负载均衡的事情让webserver做，避免出现漏洞。

[tomac4t]

首先我认为标准的HTTPS流量的实现，一定是能过CDN的(只有trojan-go是可行的)，不然肯定留有不同之处。

请不要下断言，标准的 HTTP 代理也过不了 CDN，CDN 没有动机也不可能支持 HTTP 隧道。

[darhwa]

如果所有土制协议都收敛到TLS上，那对抗性研究的范围就大为收窄，难度就大大下降了。

考虑到大量用户至今仍在使用裸的ss vmess，我觉得事实上不用担心这一点。小(规模)土(法密码学)群(众运动)的主流还是从传输层开始造。坐看众人拾柴火焰高，大寨越办越红火！

用ss的的确不少是裸的，但用vmess的？我不确定。你说的主流是以前的，新时代的主流，参考trojan

提到trojan，我多说几句吧。目前基于TLS的一些工具都活得好好的，不代表它们的安全性真的做得有多好，而是因为有外围的v2ray，更外围的ss，更更外围的VPN在吸引火力。当这些潮水都退去，谁在裸泳就一眼便知了。比如trojan，那1:1的连接模型不是太可疑了么？你开个youtube之类资源多的网页，立马能爆出30多个并发连接。如果再考虑到同时开多个网页，以及同一个路由器后面不止一个用户，这问题会更加严重。要判断某IP高度疑似在使用trojan，很难吗？

[rprx]

@hurui200320

在 TLS 之上，小流量看不出 ProtoBuf 的特征，大流量则仍会显示出原本的特征，所以需要一定程度的混淆，而多套一层意义不大

对于证书的担忧，不太可能这么做，否则是很明显的审查行为（而且只是因为小群体），他们现在都还不承认墙的存在

如果是域名白名单，DoH + ESNI 可以解决问题，除非上 IP 白名单，那就只能星链等不途径 GFW 的信道了（星链据说不支持中国）

[rprx]

@darhwa

我举trojan的例子，是为了反对你的“主流还是从传输层开始造”

我并不赞同没有混淆，我在issue中明确说“在一定程度上混淆流量以防止基于机器学习的流量分类”

但我更赞同基于 TLS 的百花齐放，“坐看众人拾柴火焰高，大寨越办越红火！”

[ActiveIce]

首先我认为标准的HTTPS流量的实现，一定是能过CDN的(只有trojan-go是可行的)，不然肯定留有不同之处。

请不要下断言，标准的 HTTP 代理也过不了 CDN，CDN 没有动机也不可能支持 HTTP 隧道。

我可能没有表达清楚我的意思。我的意思是要满足安全性和隐匿性，需要模仿普通上网的流量。从外界看来，你是在上网而不是在用HTTPS proxy。鉴于很多网站都使用了CDN技术，我认为能过CDN的流量与普通上网的特征会更为相近。如果观点不对还请指正。

[tomac4t]

如果是域名白名单，DoH + ESNI 可以解决问题，除非上 IP 白名单

ESNI 已经改名为 ECH (Encrypted Client Hello) 了。您是否真的了解 ECH？既然都可以域名白名单，那么又何尝不可检查 ClientHello 是否有 encrypted_client_hello (0xffce) 扩展，将他们一并拦截掉。

[rprx]

@tomac4t

先回复你最近的问题吧

如果我没理解错的话，你是说墙会屏蔽所有这种 TLS 流量？

[rprx]

@tomac4t

我不知道你为什么删除了你在 https://github.com/v2ray/v2ray-core/issues/2523 中的回答，希望这次不要删除，毕竟是你第二次说我离题了，这回还是在我开的issue中

关于“纵深防御”，事实上，如果有人想继续在纯 TCP 上造协议，我也无法阻止。另外，TLS 上并不是只能有一种协议，我更赞同基于 TLS 的百花齐放。

关于 TLS 指纹，并不是不可解决的问题 https://github.com/v2ray/discussion/issues/706 ，v4.23.2没有彻底解决，只是缓解（事实上，对于此问题，我正准备开新的issue作为讨论的总结与下一步建议

对于 why tls，我想我已经在 issue 中说得很明确了：参考“与时俱进的安全性、长期隐蔽”，以及“为什么当初没有直接这样设计？”

对于你们的 OT，我认为是非友好交流，不予评论

[rprx]

@blindwrite

1.我没有说SS用了TLS，但它的确遇到了TLSv1.2就已经解决的类似的问题（当然SS也升级解决了）。或许我应该这么说：“影响广泛的新问题出现时，SS又要手动改进，而不能像我主张的新协议一样直接随TLS升级”。TLS广泛应用，这是它的优势，如果SS取代TLS成正规用途且有大量流量（which is not possible），那你可以看到我支持SS而不是TLS，that's why I'm so obsess with TLS. 而我在issue中已经提到很多次了，不知道你是否能看懂中文或者说看完了整个issue。

2.NOT ALWAYS. 我们面对的不仅是协议安全性问题，还有其它问题，比如说当你看youtube时，即使套TLS，大流量的情况下仍然特征明显（取决于youtube特有的加载、缓存策略）。或者你看看 @darhwa 的回答。还有一种情况，请看看《黑镜》第一集。所以需要混淆流量，而混淆策略不会只有一种，it's diversification.

3.Can't prove. 我的意思是，基于TLS的方案和正常网页等流量混在一起，乱封会误伤所以棘手，中国还在WTO呢。但对于raw TCP的流量，若是不明协议，量再大一些，封之前没有那么多顾虑。

4.或许他想表达的是你说的意思。

5.在1中已有一些解释。我与你观点不同，我认为套TLS更隐蔽，且长期来看不折腾。

我想提醒你，加密、安全是一回事，而识别特征是另一回事。以下是我在issue里写过的话：

未来不属于自己研究了一个在纯 TCP/UDP 上就多么安全的协议：自创的方案，安全性难以比拟顶级学者设计出的 TLS 不说，不广泛使用，无论怎么设计都容易被针对。

就算哪天设计出了密码学上的安全性超越了 TLS 的方案，只有 fq 的人用，也是分分钟被针对/被机器学习特征，没有任何意义。方向错了，做的就是无用功。

或许上面的话能解释你的描述“Starting from the end of last year, we all know that raw TCP traffic got blocked while the WS traffic still works”，只是或许

[blindwrite]

@blindwrite

1.我没有说SS用了TLS，但它的确遇到了TLSv1.2就已经解决的类似的问题（当然SS也升级解决了）。或许我应该这么说：“影响广泛的新问题出现时，SS又要手动改进，而不能像我主张的新协议一样直接随TLS升级”。TLS广泛应用，这是它的优势，如果SS取代TLS成正规用途且有大量流量（which is not possible），那你可以看到我支持SS而不是TLS，that's why I'm so obsess with TLS. 而我在issue中已经提到很多次了，不知道你是否能看懂中文或者说看完了整个issue。

2.NOT ALWAYS. 我们面对的不仅是协议安全性问题，还有其它问题，比如说当你看youtube时，即使套TLS，大流量的情况下仍然特征明显（取决于youtube特有的加载、缓存策略）。或者你看看 @darhwa 的回答。还有一种情况，请看看《黑镜》第一集。所以需要混淆流量，而混淆策略不会只有一种，it's diversification.

3.Can't prove. 我的意思是，基于TLS的方案和正常网页等流量混在一起，乱封会误伤所以棘手，中国还在WTO呢。但对于raw TCP的流量，若是不明协议，量再大一些，封之前没有那么多顾虑。

4.或许他想表达的是你说的意思。

5.在1中已有一些解释。我与你观点不同，我认为套TLS更隐蔽，且长期来看不折腾。

So you cannot clarify my 3rd point, and that's sufficient to stop these arguments. Also, this is why we think your arguments are disgusting.

You've made too much assumptions and you cannot prove any of them.

For your arguments to be valid, it requires reliable sources/materials to show that the side channel emits sufficient signals to conclude that, in a given acceptable confidence level, these traffic comes from one specific protocol but not others.

Not to mention that most o the vulnerabilities discovered, if not all, are on the outermost layer. I don't want to stress this more.

Take TLS as an example, recently TLS fingerprint has been discussed. TLS is the outermost layer, and it potentially suffers from possible profiling attacks. While this may be resolved, it's still something identifiable. On the other hand, SS doesn't suffer from such.

Remember, the trade-off between connectivity and confidentiality is likely inevitable. In reality, the latter is far more difficult to achieve.

我想提醒你，加密、安全是一回事，而识别特征是另一回事。

Think twice what you've said.

[LsnmxNB]

如果所有土制协议都收敛到TLS上，那对抗性研究的范围就大为收窄，难度就大大下降了。

考虑到大量用户至今仍在使用裸的ss vmess，我觉得事实上不用担心这一点。小(规模)土(法密码学)群(众运动)的主流还是从传输层开始造。坐看众人拾柴火焰高，大寨越办越红火！

主要是域名才能vmess+ws+tls，自用10几台服务器用域名超级麻烦，所有干脆用裸的 vmess

[cpdyj]

TLS用域名是没办法的吧，绕不过去的，你不可能去弄一张IP的证书啊

在 2020/6/2 16:53, LsnmxNB 写道:
>

    如果所有土制协议都收敛到TLS上，那对抗性研究的范围就大为收窄，难度就大大下降了。

考虑到大量用户至今仍在使用裸的ss
vmess，我觉得事实上不用担心这一点。小(规模)土(法密码学)群(众运动)的主流还是从传输层开始造。坐看众人拾柴火焰高，大寨越办越红火！

主要是域名才能vmess+ws+tls，自用10几台服务器用域名超级麻烦，所有干脆用裸的
vmess

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/v2ray/v2ray-core/issues/2526#issuecomment-637394727,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADINZHCCSNCVPL4E24WXSDTRUS4XNANCNFSM4NPZFDFA.

[rprx]

@blindwrite

鉴于你这个小号总是有“disgusting”等涉及人身攻击的言论而不是就事论事，这是最后一次回复

1.特征被识别是大多数人对于封锁的解释和看法，而不只是我的。

当然，或许，你的阴谋论成立。但你就可以 prove 你的 assumption 吗？你就不 disgusting？你就很 academic？

可以参考以下几个链接（不一定完全正确或很有效，但有人在这方面努力，并且取得了一定的成果
https://twitter.com/williamlong/status/1138370560121982976
https://gfw.report/blog/gfw_shadowsocks/zh.html
https://files.catbox.moe/vmzj04.pdf
更多的不列了，一搜一大把

再提一下主动探测：用TLS后，路径分流可以让主动探测找不到目标，而不像SS这种只能原地挨打

还有其它你觉得是 assumption 的，你可以列出来（虽然我不太想回复

2.关于 TLS 指纹，你都不看我回复其他人的吗？https://github.com/v2ray/discussion/issues/706

[blindwrite]

@blindwrite

鉴于你这个小号总是有“disgusting”等涉及人身攻击的言论而不是就事论事，这是最后一次回复

1.特征被识别是大多数人对于封锁的解释和看法，而不只是我的。

当然，或许，你的阴谋论成立。但你就可以 prove 你的 assumption 吗？你就不 disgusting？你就很 academic？

可以参考以下几个链接（不一定完全正确或很有效，但有人在这方面努力，并且取得了一定的成果
https://twitter.com/williamlong/status/1138370560121982976
https://gfw.report/blog/gfw_shadowsocks/zh.html
https://files.catbox.moe/vmzj04.pdf
更多的不列了，一搜一大把

再提一下主动探测：用TLS后，路径分流可以让主动探测找不到目标，而不像SS这种只能原地挨打

还有其它你觉得是 assumption 的，你可以列出来（虽然我不太想回复

2.关于 TLS 指纹，你都不看我回复其他人的吗？v2ray/discussion#706

In my opinion I've always in line with the discussion, and I simply stated my feeling. Aren't you the one to assume ill will on others?

First of all, all your links neither comes from academic sources nor have detailed illustration on the attack. If you wonder what's qualifying, the recent one on the vmess vulnerability counts.

Don't want to be rude. You always think I was defaming you, but I'm afraid you've never be in the academic area so cannot understand what I meant.

Second, even if we assume those sources are reliable & trustworthy, all your links do not show that SS is vulnerable. How's the accuracy on that neural network? How many SS server got compromised due to active probing?

For TLS, fingerprint is just one of the possible attack vectors. Remember, TLS is NOT for confidentiality by design, even if it achieve such a goal, partially or not. I took TLS fingerprint as an example simply to illustrate why we don't really need TLS. Shamelessly stole what @tomac4t said,

TLS 指纹问题已经说明这一点了。模仿其他协议终究会因为无法完美模仿而被发现，即鹦鹉已死。

[ActiveIce]

@blindwrite
If you think ss is ok, just use it. It's not necessary to quarrel here.
Some users' ss servers were banned soon after the connection was established. And some users use it normally. I don't meant that the content in ss is not save, but ss server can be detected for sure.
Use Chromium's network stack in client side might be a good solution to solve the fingerprint problem.

Feel free to use what you thust.

[blindwrite]

@blindwrite
If you think ss is ok, just use it. It's not necessary to quarrel here.
Some users' ss servers were banned soon after the connection was established. And some users use it normally. I don't meant that the content in ss is not save, but ss server can be detected for sure.
Use Chromium's network stack in client side might be a good solution to solve the fingerprint problem.

Feel free to use what you thust.

You misunderstood one important thing, and that's also the most important one.

Getting ban does NOT indicate that the traffic got sniffed, or the protocol is compromised. Nowadays you may even be able to use severely outdated protocols like PPTP without any problem, and there's still so many SS providers that keep using non-AEAD implementation, but it's highly recommended not to use them. Also, the blocking may be trigger simply by factors like the traffic amount made in unit time, it's never a good indicator on evaluating the cryptosystem.

As a tool to circumvent censorship, confidentiality is always the first to consider, and undoubtedly SS did a good job, at least unlikely to cause catastrophies.

[ActiveIce]

@blindwrite
There is users who use latest AEAD ss still be banned few minutes after deploy. But not all users have this problem.
Maybe you should read what I've said. I agree that, undoubtedly AEAD ss has good cryptosystem. But its too easy to distinguish between ss and https traffic.
Maybe your network environment only need AEAD encryption. But in some users' case they need more than AEAD encryption.

Due to different network environments, feel free to use what you can use and trust. If you think ss is the best, it's no need to ask developers to make vmess another "ss". Just use it.

[rhjdvsgsgks]

If you think ss is the best, it's no need to ask developers to make vmess another "ss". Just use it.

反对这句话，按你这么说如果基于tls是不是可以说是 ask developers to make vmess another "trojan".

[rprx]

If you think ss is the best, it's no need to ask developers to make vmess another "ss". Just use it.

反对这句话，按你这么说如果基于tls是不是可以说是 ask developers to make vmess another "trojan".

反对你的说法，因为基于 TLS 是大多数人认为的未来的方向，这已经是客观事实
trojan 等其它基于 TLS 的新协议出来得比较晚，走在了必经之路的前面而已

或许你们有空看看其它 issue 中现在在讨论什么，去和他们说，而不是只在这里发言
https://github.com/v2ray/v2ray-core/issues/2523 and https://github.com/v2ray/discussion/issues/711

[ActiveIce]

@rhjdvsgsgks
他说和SS同方案，完全AEAD加密就行，那确实已经没有再写的必要。
我可没有说trojan是完美的，tls的实现，服务端反代谁放前面等等是有区别的，我前面也说了针对trojan的分析。
之所以这么说，还是希望不要极端化了。不要随便说某某方案就ok了，然后去无视一些人用不了的反例。基于现在的多种方案，结合他们的优点不好吗。

坚持要基于TCP开发协议的，我认为不要说直接基于TCP有多好，是要指出一些SS的问题，给出可能可行的优化方案就好了。
坚持要使用TLS的，也要总结一些目前TLS的问题，然后结合其他实现给出一些方案。就Trojan来说，将服务端放在webserver之后，相对能更好避免代码漏洞的潜在风险。客户端参考naiveproxy，或许能更好的避免指纹问题。

这个issue已经快60评论了，我希望讨论不要局限于用A打倒B，再用B打到A，这样评论上百也是没有用的。希望还是多总结一些之前的问题，然后提出改进，哪怕只是可能可行，甚至错误的改进，都对讨论是有促进作用的。
当前存在xx问题，使用xx方案，具有xx特性，可以对该问题有改善作用。我希望看到类似的建设性讨论。用A+改进A，用B+改进B。

[rhjdvsgsgks]

反对你的说法，因为基于 TLS 是大多数人认为的未来的方向，这已经是客观事实
trojan 等其它基于 TLS 的新协议出来得比较晚，走在了必经之路的前面而已

或许你们有空看看其它 issue 中现在在讨论什么，去和他们说，而不是只在这里发言

2523 and v2ray/discussion#711

我认同你的反驳，我也看到了，确实支持 tls 的声音比较高，而且使用 tls 能起到藏木于林的效果。我现在只是希望 v2ray 能不要放弃基于 tcp 的 vmess 协议的维护，我个人还是比较喜欢直接基于 tcp 的，也许只是因为他更底层/少一层协议能使数据在整个包中所占的比重更大些或rtt少些(用词好像不怎么准确)，也许只是因为 tls 并不是专门为翻墙而生无法做到某些 tls 不擅长而为翻墙而生的专有协议擅长的事(比如隐藏服务器域名，现有的vmess可以只要个ip就能连接，但tls需要验证服务器域名与证书域名是否一致，在这过程中就会暴露域名，至少目前 esni/ech和dot/doh还没有推广开来的时候是这样的)，但这并不能掩盖支持tcp的只有寥寥几人的事实

[yeahwu]

你们有没有考虑过小白用户的需求？tls香吗？香，但是你得有个域名，配置dns，申请证书，还得配置web服务等等。这些对于小白来说，是不是复杂了点？你们是打算搞出来程序猿团体用吗？
tls安全吗？某人说过“使用服务越多，中间环节越长，越会增大攻击面。”你们可以看看这个tls的链路有多长。
tls有效率吗？这个不用多说，自己对比vmess-tcp的速度就知道了。
俺是建议，轮子该造还是得造，多为普通用户考虑一下。

[rprx]

@ActiveIce

@blindwrite 的问题是，他根本是在无理取闹，最终会要我们给出根本无法得到的 GFW 内部数据，证明GFW的确识别SS才满意，而无视社区经验和大量相关研究。他引用 @tomac4t 的言论本身就有问题，因为我们是使用而不是模仿TLS，要说模仿也是模仿浏览器的TLS指纹，而这实际上是不成问题的。

@tomac4t 的问题是，他根本没有继续回复，而是在thumbs down却不说理由。以及他搬出“学术”、“论文”等字眼，说得好像别人没受过相关专业的高等教育一样。但我不会天天把这些挂嘴边。

说到thumbs down，此issue正文中第二个thumbs down的人根本不理解tls原理，有兴趣可以翻翻我以前的issue。但他也用tls，还曾经希望默认allowInsecure。我有理由怀疑他站GFW那边。

我是就事论事的人，一般不针对谁。但我时间不是用来浪费在这些人身上的。

[rhjdvsgsgks]

@ActiveIce 确实，我的回复有些操之过急了，在 上一条回复 中我列出了一些我认为tls目前使用可能做的不够完善的地方，希望对开发能有所帮助

[rprx]

你们有没有考虑过小白用户的需求？tls香吗？香，但是你得有个域名，还得申请证书，还得配置web服务等等。但是这些对于小白来说，是不是复杂了点？你们是打算搞出来程序猿团体用吗？
tls安全吗？某人说过““使用服务越多，中间环节越长，越会增大攻击面。”你们可以看看这个tls的链路有多长。
tls有效率吗？这个不用多说，自己对比vmess-tcp的速度就知道了。
俺是建议，轮子该造还是得造，多为普通用户考虑一下。

事实上，小白通常用机场。而用VPS的话，本身应该有相关知识，即使没有，也可以注册域名+一键脚本。tls安全吗？这应该不是个问题。tls有效率吗？在这里，效率是最后才要考虑的。不然，干脆裸socks5。而且，tls方式的效率并不只取决于它本身，还可能有ws/h2/h3。

关于效率的补充：阉割版vmess+tls不见得比现在的vmess over tcp慢很多。不能拿现在的vmess over wss 来说明问题，毕竟有很多多余特性降低性能，设计时也不是专门与tls相适应。

[tomac4t]

@rprx 我重新审视了我的评论，我没有说 TLS 不好，我说的是 @klzgrad 的观点没有问题，他本身是 naiveproxy 的作者，为什么要反对 TLS？我说的是你的很多断言是错误的，我已经指出了，比如翻墙协议“必须基于 TLS”，“其他都该淘汰”，我举了不少例子反驳你，现在你用了删除线删除了你的断言。那不就没事了，我不也没回复的必要。

• uTLS 的问题在于它只处理 ClientHello，能不能成功协商它不管。这本身就是一个问题，即《鹦鹉已死》中提到的动态行为。

• ECH 的问题在于他在 ClientHello 发送特定的扩展 (0xffce)，就和 SNI 扩展一样。你的前提是 SNI 白名单，那么 ECH 也可直接屏蔽。FOCI' 19 的论文 探讨过这个，并且引用了报道，称韩国已经做么做了：https://web.archive.org/web/20190616020542/https://www.bleepingcomputer.com/news/security/south-korea-is-censoring-the-internet-by-snooping-on-sni-traffic/ 但论文作者无法证实。

许多论文的结论都是客观可靠的，而不是非常主观地下结论，这就是我引用的目的。同时一些论文能够保证你不必不切实际的乱想。我重新审视了我的评论，没有一处带有攻击行为（而有几位的评论明显是对人不对事的），也无意涉及 Shadowsocks 好坏的任何争论，这就是我不回复的原因。

---

@klzgrad 我注意到你订阅了 traffic-obf 邮件列表（因为我也在里面），不过那个已经不再活跃了，关注一下 Tor anti-censorship 的仓库么：https://github.com/net4people/bbs/issues 大多都是同波人马，内容主要是一些论文的摘要。

[blindwrite]

@rprx What you said this time really angers me.

@ActiveIce

@blindwrite 的问题是，他根本是在无理取闹，最终会要我们给出根本无法得到的 GFW 内部数据，证明GFW的确识别SS才满意，而无视社区经验和大量相关研究。他引用 @tomac4t 的言论本身就有问题，因为我们是使用而不是模仿TLS，要说模仿也是模仿浏览器的TLS指纹，而这实际上是不成问题的。

Take SS as an exmaple, the deprecation of OTA is not pushed by the community? The recent vmess vulnerability is not discovered by the community? I never sais I did not accept these sources, but the problem is, you cannot provide one.

What I really want to say has already been expressed by @tomac4t , that

• @klzgrad is not wrong, and
• TLS is not the only candidate for future vmess implementation.

And personally, I want to add that, from my personal opinion,

• The root cause of the vmess vulnerability comes from not using AEAD.
• The outermost layer is what we really care; side-channel attack in the inner protocol is not something we really need to consider right now.
• The assumption of "sneaking traffic into the sea of TLS" has no security implication on TLS, so it's not a valid argument for promoting TLS.
• Using TLS or any other similar public practices potentially introduces side-channel attacks (e.g.TLS fingerprint), but it's possible (and very likely) that a dedicated scheme can get rid of these all together.
• Using TLS as the outermost layer may not be a good choice in the long run, as the diversification suffers.

That's all I want to say. I don't know why you're so triggered right from the start.

@tomac4t 的问题是，他根本没有继续回复，而是在thumbs down却不说理由。以及他搬出“学术”、“论文”等字眼，说得好像别人没受过相关专业的高等教育一样。但我不会天天把这些挂嘴边。

(off-topic) he actually provided several very good academic resources, have you read them?

说到thumbs down，此issue正文中第二个thumbs down的人根本不理解tls原理，有兴趣可以翻翻我以前的issue。但他也用tls，还曾经希望默认allowInsecure。我有理由怀疑他站GFW那边。

我是就事论事的人，一般不针对谁。但我时间不是用来浪费在这些人身上的。

This is not the place for conspiracy.

[rprx]

@tomac4t

因为你在其它issue中删除了对我的回复，然后这里又不回复，让我比较困惑。

事实上，那仍是我及其私人的观点，我用删除线是因为有些人没有看到“个人认为”，所以干脆不再夹带私货。另外我认为，有些人对vmess投入大量精力，应该尊重他们的劳动。况且，有些人想继续开发vmess，和我并没有利益冲突，所以我最终选择求同存异。

说实话，我之前没有看到 @klzgrad 写了 naiveproxy，现在再回去看，我算是明白他的意思了：v2ray继续研究并带动其他人研究类似vmess的协议以吸引火力掩护我。我之前并没有看懂“所以v2ray协议设计越丑陋，其实就越有韧性。”，现在算是明白“v2ray最大的力量”在于掩护。那么，我也没意见。

我一开始站的是what‘s good for v2ray而不是将v2ray作为某种程度上的牺牲品，摆脱这个想法就没问题了。

对于uTLS是否完美，我相信copy chromium的实现会更像浏览器。

黑名单SNI阻断，中国也早已经在做了。对于ESNI/ECH的问题，如果全部屏蔽那么白名单网站也会被波及，所以我并不认为这件事会发生。对于你刚列举的论文，我有空时会看。

[rprx]

@blindwrite

不光你。我早已经很生气，并且真的不想再在这里纠结下去了。

我本来打了很多字，但我还是精简成几句话吧。

首先，如果你认为 SS 安全且不被识别，你尽管用就好了，没人拦着你用。

其次，既然 SS 很安全且不被识别，那有它就够了，无需再设计更多基于纯 TCP 的协议。

事实上，一些协议/插件就考虑到了混淆的情况，这是多余的吗？
对于这些协议可能的流量特征，本issue恰好就有人提到 https://github.com/v2ray/v2ray-core/issues/2526#issuecomment-637310092

如果你想要相关研究，我给你的你不满意，为何不自己去搜？或许你可以搜到很多。
我是想说，更多的人认为SS有特征，你可以去和他们辩论，而不是我。

的确，我们没有GFW内部数据，并不知道它是真的识别出来了还是乱封。
因为我只是持有和大多数人相同的观点，即SS可被识别。
且当新的未知的广泛性安全性问题出现时，SS又要手动升级。

至于你对采用 TLS 的担忧，有一定价值，但不完全正确。

off-topic：

因为你不知道 @tomac4t 在 #2523 中也有让我迷惑的行为，而刚刚他在这里又没有回复，让我更迷惑了，但我没有说他提供的资料有问题，请你分清重点。

至于“This is not the place for conspiracy.”，不是你说了算。况且你一开始就有阴谋论。

不再回复。

[blindwrite]

@blindwrite

不光你。我早已经很生气，并且真的不想再在这里纠结下去了。

我本来打了很多字，但我还是精简成几句话吧。

首先，如果你认为 SS 安全且不被识别，你尽管用就好了，没人拦着你用。

其次，既然 SS 很安全且不被识别，那有它就够了，无需再设计更多基于纯 TCP 的协议。

事实上，一些协议/插件就考虑到了混淆的情况，这是多余的吗？
对于这些协议可能的流量特征，本issue恰好就有人提到 #2526 (comment)

如果你想要相关研究，我给你的你不满意，为何不自己去搜？或许你可以搜到很多。
我是想说，更多的人认为SS有特征，你可以去和他们辩论，而不是我。

的确，我们没有GFW内部数据，并不知道它是真的识别出来了还是乱封。
因为我只是持有和大多数人相同的观点，即SS可被识别。
且当新的未知的广泛性安全性问题出现时，SS又要手动升级。

至于你对采用 TLS 的担忧，有一定价值，但不完全正确。

off-topic：

因为你不知道 @tomac4t 在 #2523 中也有让我迷惑的行为，而刚刚他在这里又没有回复，让我更迷惑了，但我没有说他提供的资料有问题，请你分清重点。

至于“This is not the place for conspiracy.”，不是你说了算。况且你一开始就有阴谋论。

不再回复。

I think i need to clarify something.

You and ActiveIce both assume I advocate SS, and that's straight false accusation.

Right from the start, i stated the current vmess problem comes from not using AEAD, how come this becomes me "promoting SS"?

至于你对采用 TLS 的担忧，有一定价值，但不完全正确。

All the points I listed, you did zero discussion but straight up blast a conclusion. You never explain why I'm wrong, never.

说实话，我之前没有看到 @klzgrad 写了 naiveproxy，现在再回去看，我算是明白他的意思了：v2ray继续研究并带动其他人研究类似vmess的协议以吸引火力掩护我。我之前并没有看懂“所以v2ray协议设计越丑陋，其实就越有韧性。”，现在算是明白“v2ray最大的力量”在于掩护。那么，我也没意见。

This indicates that you never try to understand others but keep insisting your opinion, not until sometime pointed that out again and again.

Thanks to your hard work, this thread has fallen to blatant accusation and no longer be able to go back to the right track. Nicely done!

[rprx]

@blindwrite

问题是若 SS 安全且不被识别，为什么还要改进vmess，甚至创造更多这种协议，你可以解释一下吗？我当然坚持我的观点，但你的观点前后是自相矛盾的你没发现吗？至于AEAD，我已经说了“如必须的 AEAD 加密改进”，这是众所周知的事情。

[rprx]

@blindwrite

至于为什么一笔带过TLS，是因为现在已经很晚了，而且我单纯不想和你讨论。

[rprx]

@blindwrite

"This indicates that you never try to understand others but keep insisting your opinion"

是你没理解他的话还是我没理解他的话？他支持多样性，那样战火不会都集中到TLS上，对吧？但从另一种意义上来说，非基于 TLS 的协议难道不是某种程度上的牺牲品吗？毕竟社区花时间花精力和 GFW 对抗你来我往，与此同时 TLS 的却没被封多少。

[darhwa]

@blindwrite @rprx Why waste so much time on such a nonsense talk? Your enemy is not each other.

[blindwrite]

Please don't spam posts.

@blindwrite

问题是若 SS 安全且不被识别，为什么还要改进vmess，甚至创造更多这种协议，你可以解释一下吗？我当然坚持我的观点，但你的观点前后是自相矛盾的你没发现吗？至于AEAD，我已经说了“如必须的 AEAD 加密改进”，这是众所周知的事情。

Because of the vulnerability discovered yet not patched, vmess needs to be upgraded, and that has nothing to do with SS.

Please stop assuming "non-TLS implementation == SS", this is not funny, serious.

Here, i want to quote what @rhjdvsgsgks said

我现在只是希望 v2ray 能不要放弃基于 tcp 的 vmess 协议的维护

I think i've made this very clear.
https://github.com/v2ray/v2ray-core/issues/2526#issuecomment-637269719

Actually it's exactly the same idea as @klzgrad mentioned, what we need is another protocol based on TCP but not TLS.

This does not mean TLS is problematic, I really don't want to emphasize this explicitly again.

====

至于为什么一笔带过TLS，是因为现在已经很晚了，而且我单纯不想和你讨论。

From this thread, we can see that TLS widens the attack surface. Assume TLS is not used, we don't need to deal with unnecessary aspects like the fingerprints, the ESNI, and potentially more if there's more extensions. These surely not factors against the use of TLS, but think about it: for example, , is ESNI needed on TLS? Is it a mandatory part in an implementation based on raw TCP?

You may think it's not important, but to me it matters.

====

是你没理解他的话还是我没理解他的话？他支持多样性，那样战火不会都集中到TLS上，对吧？但从另一种意义上来说，非基于 TLS 的协议难道不是某种程度上的牺牲品吗？毕竟社区花时间花精力和 GFW 对抗你来我往，与此同时 TLS 的却没被封多少。

For the cost of countering, check my first post on this thread (same link as above).

For other non-TLS implementations being blocked, I've already answered here
https://github.com/v2ray/v2ray-core/issues/2526#issuecomment-637468724

====

@blindwrite @rprx Why waste so much time on such a nonsense talk? Your enemy is not each other.

I have to admit that I'm not really acting rational, but anyway.

====

In my opinion,

• if one cares more about a working tunnel, (the existing) TLS solutions are good enough.
  
  
  
  • If unobservability is more important, a raw TCP implementation should be preferred.
  
  
  • The above two do NOT interfere each other. (I wonder why I need to emphasize this?)
  
  

[ActiveIce]

为了有效讨论，根据各位的发言和一些我个人的思考，我想总结一下。

考虑到v2ray本身是个网络工具平台，我想不能狭义的将它理解为科学上网的工具。在一些场景下，如不受审查的两台主机之间进行加密通信，如果使用TLS，消耗的rtt就会很多。综合考虑多种场景的使用也是蛮重要的。总结方案如下

1.vmess保持无状态协议，包含鉴权，明文。流量可设为通过TCP或UDP传输
2.加密层，可以通过配置文件开启，为明文vmess加上完整的AEAD加密
3.传输层，可以通过配置文件开启，将明文vmess或者AEAD加密后的vmess套上ws/h2c
4.TLS层，把ws/h2c变为wss/h2，且具有能通过CDN的特性
5.为了减少服务端暴露在外层风险，保持v2ray能被webserver反代的特性，将流量识别与分流依然交给webserver处理
6.若配置文件使用了wss/h2，客户端即采用chromium网络层进行流量的发送，因uTLS方案有行为模仿不充分的潜在风险。

这样的设计可以满足大家的各种需求，不论是局域网可信网络内的明文高效传输，还是两台互联网主机之间的单纯加密传输，免握手的UDP传输需求，科学上网的需求，无webserver用户，有webserver用户，都有了最为高效安全的方案。而且各层次之间比较分明，兼容性好，可以任意按需求进行组合。

有更好改进可以进一步讨论。

[rprx]

@blindwrite

说实话，非理性的讨论，根源是你一开始就使用 disgusting 这种词，让我感到不舒服。
那么，我尽量理性和你讨论一下。

我是觉得有矛盾的地方。

首先，根据你的看法，现在的ss是安全且无特征可识别的。
那么，升级后的vmess，在GFW看来，和ss没有区别，对吧？（无特征可识别）
而我们的目的是什么？是安全翻墙。无论用ss还是升级后vmess，我们的目的都可以达到。
那么，为什么有必要去升级vmess而不是直接采用ss？毕竟在墙看来没有区别。
如果想要vmess的鉴权功能，那么，可以，升级vmess。
但既然我们的目的已经达到了，墙也抓不住特征，有什么必要继续创造其它基于 TCP 的协议呢？这一点我不明白，serious. 希望你可以解答。

你有没有想过，问题的根源是你基本事实认知偏差？
@klzgrad 说那些话，他的认知是，不同协议有可识别特征（所以需要多样化），这也是主流认知。
当然，在此我们不要再对这一认知进行探讨，我不是你最合适的对象。

====

以及，请不要揣测我“You may think it's not important”，我更认为“it matters”

本来这个issue讨论的就是基于 TLS 的方案如何设计，实际上，我当时正准备对 @ActiveIce 的描述做进一步补充，然后有人提出“我旗帜鲜明地反对在v2ray里面直接使用TLS”，我对他进行了反驳，接着你就带着“disgusting”来了，并把话题拉到了“如何证明SS可被识别”，导致后面一直离题，且使人耗尽精力

你没有意识到，并不是我只想和你讨论那些，而是我不得不回复你（因为我不认同你说的话）

还有，实际上重点是设计，即确定我们要哪些功能、不要哪些功能、形式是怎样的
而不是单纯在这里论证 TLS 的安全性（这很重要，但不是重点

[rhjdvsgsgks]

如果把加密从 vmess 里分离出来是不是就可以解决上述使人产生不愉快的争吵的问题了，如果想用 tls 可以 tcp+tls+(ws/h2/quic)+wmess ，如果想用 tcp 可以 tcp+vmess+加密。
或者说直接完善现有的协议是不是更好，前者可以视为直接在现有的一系列协议上进行修改，使其在使用 tls 时避免和 vmess 中重复的功能(如加密)造成性能损失，后者可以视为为现有的 vmess(tcp) 更新 aead 加密

[ActiveIce]

是的是的，考虑到多种网络场景，很有必要这么搞，详见我上面的方案

[rprx]

@ActiveIce

RTT不是最大的问题，因为会用长连接，且TLSv1.3可以做到0-RTT

[KevinZonda]

Reinvent Trojan. XD

[blindwrite]

首先，根据你的看法，现在的ss是安全且无特征可识别的。

I've never said that.

Security is something ongoing; nothing will be secure forever.
A worthy cryptosystem lives as long as it's unlikely to be in a state of compromised.

而我们的目的是什么？是安全翻墙。

Different groups of people demand different levels of security assertion. Deemed secure for a normal folk doesn't mean it's sufficiently secure for sensitive groups.

那么，为什么有必要去升级vmess而不是直接采用ss？毕竟在墙看来没有区别。

Again, if you're on the perspective that "a working tunnel is sufficient", then all these implementations have only 2 states, working, and not working. You really think this classification is sufficient in the context of cryptosystem security? Not to mention "a working tunnel" actually has nothing to do with the cryptosystem security.

As long as the implementations differ, it takes extra resources to deal with another set of cryptosystem. As long as the implementations keep updating, the cost on defeating it becomes higher.

但既然我们的目的已经达到了，墙也抓不住特征，有什么必要继续创造其它基于 TCP 的协议呢？这一点我不明白，serious. 希望你可以解答。

Again, you make an assumption that "not getting block == no identify captured". You will never know if it silently profiling your traffic. But if the implementation keeps following the latest essays, it's likely that the risk of being cracked is minimalized.

@klzgrad 说那些话，他的认知是，不同协议有可识别特征（所以需要多样化），这也是主流认知。

本来这个issue讨论的就是基于 TLS 的方案如何设计，实际上，我当时正准备对 @ActiveIce 的描述做进一步补充，然后有人提出“我旗帜鲜明地反对在v2ray里面直接使用TLS”，我对他进行了反驳，接着你就带着“disgusting”来了，并把话题拉到了“如何证明SS可被识别”，导致后面一直离题，且使人耗尽精力

For "disgusting", I've used it twice, and I've clarified that

That's purely subjective view, you can dismiss that.

But I think you've used that word 4 times across this thread? Who's keep bringing this up?
By the way, I think you like the hammer of "阴谋论"?

Also, it's you who leads it to “如何证明SS可被识别”, right from the start my opinion is "TLS is not really necessary", and you try to attack me by pointing out potential vulnerabilities on SS. Who's causing chaos?

I really did the discussion but I really don't see anything worthy here.
https://github.com/v2ray/v2ray-core/issues/2526#issuecomment-637269719
https://github.com/v2ray/v2ray-core/issues/2526#issuecomment-637304549
https://github.com/v2ray/v2ray-core/issues/2526#issuecomment-637380194
https://github.com/v2ray/v2ray-core/issues/2526#issuecomment-637425317
https://github.com/v2ray/v2ray-core/issues/2526#issuecomment-637468724
https://github.com/v2ray/v2ray-core/issues/2526#issuecomment-637575290
Given my point of view is that "TLS may not be necessary", can someone tell me which one is off-topic?

And, just to remind, the original post is about ditching non-TLS implementations, so please don't accuse me of off-topic on not talking directly on TLS implementation.

个人认为，非 TLS 方案都应该被淘汰，不要再浪费时间了。就像我说过的，很多人直到 2020 年都还没有抓住重点：从 SS 到 SSR 再到 VMess，总是想着直接在 TCP 上设计协议，却没有一个能长久。未来不属于自己研究了一个在纯 TCP/UDP 上就多么安全的协议：自创的方案，安全性难以比拟顶级学者设计出的 TLS 不说，不广泛使用，无论怎么设计都容易被针对。就算哪天设计出了密码学上的安全性超越了 TLS 的方案，只有 fq 的人用，也是分分钟被针对/被机器学习特征，没有任何意义。方向错了，做的就是无用功。v2ray/discussion#711

Time to stop this shit show.

[ActiveIce]

@rprx 我那个整体架构方案你觉得哪里要改进，可以指点一二。
我在用0RTT的tls1.3(haproxy实现)，很舒服。我考虑到局域网vmess明文传输最佳，公网之间通信UDP没被QoS的话，vmess加密+UDP最佳，有QoS则使用vmess加密+TCP，科学上网可以用vmess明文+wss/h2，不放心CDN的朋友可以vmess加密+wss/h2。遂做出此分层的设计。

[Kylejustknows]

1， 底层协议的难点不在于加密，（数据部分加密不管是直接使用TLS1.3还是使用TLS认证过的那些加密算法，都很容易实现）； 难点在于身份认证段，如何添加身份认证后还能避免攻击和嗅探；
2，TLS的使用范围有限，需要域名、外网链接、证书等，而V2Ray作为一种流量转发工具，可以用来制作很多复杂的内网间和跨域的流量中转通道。如果纯粹为了翻墙，去试试Trojan吧纯TLS，但如果一旦你开始需要更复杂的多层内部流量中转机制，还得回到自有协议的V2ray上来。

[rprx]

@blindwrite

新的一天，从头来过。

TLS 是什么时候有 AEAD 加密方式的？正式发布于 2012 年。SS 是什么时候才进行此项改进的？2017 年。而 VMess 是什么时候？not yet。
所以我想表达的是，TLS 在密码学上的安全性是走在我们自制的 SS、VMess 前面的。
而且如果再有新的波及广泛的问题出现，TLS 的升级速度会比 SS 快，毕竟这是整个互联网的问题，有大量学者在研究、设计、寻找漏洞，这一点你无法否认。
就像本次 VMess 的问题，如果不是有人专门对 VMess 的安全性进行研究，那不知何时才能发现。
这是采用 TLS 的优势之一，即在密码学上的安全性有与时俱进的保证。而 SS 若也存在那种问题（如果有人发现的话），需要再次手动升级，这也是需要折腾的地方。

其次，使用 TLS 可以进行路径分流，这是优势之二。
你当然可以说，没有证据表明现在的 SS 可以被主动探测。但是，比起来“可以接触”，让墙根本找不到目标（同时还被迷惑）不是更好吗？
如果用白名单的思路进行主动探测，那么 SS 的固定端口无法探测到任何已知正常协议，同时却有大量连接、流量，这对墙来说意味着什么？
正如你所说的，raw TCP的流量被大量阻断。
事实上，你可能忽略了，采用 TLS 并不只有密码学上的安全性，还可以欺骗 GFW 让其迷惑，而 SS 则没有额外的这种作用。SS 无法做到藏在 443 端口后面，无法藏木于林。

====

当被动安全性问题、主动探测问题都被暂时解决后，需要考虑的是什么？下一步。这是我多次提到可能被识别的“流量特征”的原因，而这也是本来就要考虑的。
因为我不质疑 TLS 目前的安全性，同时它无法被主动探测。正如我所说的，对我来说，这些问题已经被解决了，至少现在是这样。
但你总是想着在纯 TCP 上创造协议，所以前面的那些问题是你仍然要考虑的，这是我们不在同一个频道上的原因。
同时，这也是直接使用 TLS 的优势（而不是其它用AEAD加密的方式），即减轻心智负担、减少要考虑的问题。而如果在纯 TCP 上创造协议，则没有这种优势。
同时，你也没有回复我的问题：我们为了 fq 而设计的这些土制协议，有非基于纯 TCP 不可的原因吗？
当然，我不否认，如果还有人用基于纯 TCP 的协议，TLS 从某种程度上来说不会那么被针对。

和 SS 不同，TLS 并不只在于它的安全性，TLS 并不是无特征，而是明确告诉墙：我就是 TLS（至少现在是这样），这是优势。
TLS 指纹是问题吗？是。但并非不可解决。如果想做到握手阶段完全模仿浏览器，大可直接用chromium的代码。
此外，我也不认为 TLS 本身有什么不可解决的问题。正如我所说的，外层已经安全，所以我在想下一步，即内层的流量特征。
但是你一直在强调，大多数漏洞位于最外层。因为对你来说你是直接暴露的，你的思路始终要停留在外面。
至于“内层的流量特征”，这是大多数人的看法和正在研究的问题，请注意是“正在研究”。
而这些研究并没有外层漏洞那么一针见血，这是属性决定的。

====

正如你所说的，我无法完全证明 SS 易受攻击，或者说有多少服务器因为主动探测而受到威胁。
但上面，我也表明了选择 TLS 而不是 SS 这种纯 TCP 协议的原因。
你说“实际上我们不需要TLS”，我希望看到你关于此观点更多的理由，而不只是 TLS 指纹，我真的需要更多理由。
毕竟我采用 TLS 之后，无需像你一样关心太多外层问题、彻底不需要关心主动探测问题，还可以告诉墙“我就是TLS”，藏木于林。
TLS 的目标是提供一个安全的外层框架，使内部内容不被破译。这是比我们更厉害许多的学者们天天在研究的框架，为什么不用？

你说 SS 被封不代表流量被识别，的确，但是是被怀疑。你说被封可能仅由大流量触发，不能用于评价密码系统。
对于流量特征这种另一层面的问题，你又强行拉回到了外层问题。因为你认为问题始终在外层。
我在这里说的“流量特征”，并不是在破解 SS，不是也不用破解它的外壳，这与外层密码学问题无关。
事实是，很多协议、插件本身就考虑到了混淆流量特征这种问题，而这也是一直以来的主流思路。

https://zh.wikipedia.org/wiki/Shadowsocks

请注意，外层的密码学问题，并不是 Shadowsocks 设计时首要考虑的。请你看看这个链接，尤其是“安全性”和“插件”部分。
那么，出于隐藏自己的目的而使用 TLS，本身就是这种思路之下的方案。不然你以为什么叫“Shadow”？
但是，对你来说，与社区思路背道而驰，你的方向是反过来的：The outermost layer is what we really care; side-channel attack in the inner protocol is not something we really need to consider right now.

你的落脚点始终纠结于 SS 的外层安全性，但社区的主流思路一直是“混淆隐蔽自身、减少流量特征”，这是矛盾的根本原因。

====

这个回复比较长，是因为我从头看完了我们的讨论，其中我写的很多内容是重复并且可能反复的，但我想你能提炼出重点。

对于你情绪化的言论，在国际上，第一个开枪（人身攻击）的国家总是罪魁祸首，其它不做回复。

[rprx]

1， 底层协议的难点不在于加密，（数据部分加密不管是直接使用TLS1.3还是使用TLS认证过的那些加密算法，都很容易实现）； 难点在于身份认证段，如何添加身份认证后还能避免攻击和嗅探；
2，TLS的使用范围有限，需要域名、外网链接、证书等，而V2Ray作为一种流量转发工具，可以用来制作很多复杂的内网间和跨域的流量中转通道。如果纯粹为了翻墙，去试试Trojan吧纯TLS，但如果一旦你开始需要更复杂的多层内部流量中转机制，还得回到自有协议的V2ray上来。

其实，新协议不影响v2ray的“流量转发工具作用”
为了翻墙，是基于tls的新协议
不为了翻墙又需要身份认证等，去掉tls即可
而v2ray原有的路由等机制可以复用
这也是我比较想给v2ray引入一种这样的协议的原因

[rprx]

@rprx 我那个整体架构方案你觉得哪里要改进，可以指点一二。
我在用0RTT的tls1.3(haproxy实现)，很舒服。我考虑到局域网vmess明文传输最佳，公网之间通信UDP没被QoS的话，vmess加密+UDP最佳，有QoS则使用vmess加密+TCP，科学上网可以用vmess明文+wss/h2，不放心CDN的朋友可以vmess加密+wss/h2。遂做出此分层的设计。

很多关于设计的想法是相似的，晚些时候我可能会重新开一个issue，包括更具体的方案及如何解决潜在的问题（而不是纠结要不要TLS），感谢你的思考，到时会@

[blindwrite]

Can it stop?

和 SS 不同，TLS 并不只在于它的安全性，TLS 并不是无特征，而是明确告诉墙：我就是 TLS（至少现在是这样），这是优势。

This is exactly the disadvantage. The more the firewall knows, the worse it will be.
TLS stands for "Transport Layer Security", it emphasizes on the security on the transport layer, but not the unobservability.

Think about such a scenario, if one day it declares that all the unauthorized foreign TLS traffic is illegal, the forensic system can provide sufficient evidence on that. But if it declares that "xxx protocol is illegal" while such a protocol achieves unobservability, it's hard to take one to the court.

请注意，外层的密码学问题，并不是 Shadowsocks 设计时首要考虑的。请你看看这个链接，尤其是“安全性”和“插件”部分。

I wonder why you still take such outdated information. The firewall is unlikely to decrypt non-AEAD SS traffic, but why SS switched to AEAD? In practice, a lack of unobservability implicates that,

• your traffic may be blocked, or even worse,
• you will be labeled as using illegal methods to circumvent existing measures, taking tickets from the court (THERE'S PRECEDENCE).

From the references of that wikipedia page, referring to what @henrypijames said,

至于说“墙没必要这样大动干戈对付影梭用户”，就更是掩耳盗铃了。我们完全有理由相信，影梭用户中有一部分已经是或可能成为“国家敌人”级别的人（至少原作者本人众所周知已经是了）。在某些特定场景下，完全可以想象墙有针对性地动用国家级别的资源来对付这样的用户。TOR一开始就定位于保护“国家敌人”级别的用户（更不用说PGP不但做出如此定位，而且作者为了保护未知的潜在的不特定的“国家敌人”用户，不惜自己成为国家敌人），那么作为应用场景十分类似（类似到很多普通用户无法区别的地步）的影梭，没有理由不作相同的安全定位。

--

你的落脚点始终纠结于 SS 的外层安全性，但社区的主流思路一直是“混淆隐蔽自身、减少流量特征”，这是矛盾的根本原因。

As mentioned above, TLS is not designed for unobservability. The parrot is dead.
Also, please stop mentioning SS, I never promote/endorse SS. Why everyone keeps mentioning SS????

--

Finally I will try to learn from @tomac4t and stop answering those nonsense.

@rprx 我重新审视了我的评论，我没有说 TLS 不好，我说的是 @klzgrad 的观点没有问题，他本身是 naiveproxy 的作者，为什么要反对 TLS？我说的是你的很多断言是错误的，我已经指出了，比如翻墙协议“必须基于 TLS”，“其他都该淘汰”，我举了不少例子反驳你，现在你用了删除线删除了你的断言。那不就没事了，我不也没回复的必要。

Unsubscribed.

[ActiveIce]

我想补充一点刚想到的。没有永远安全、绝对安全的协议，我们需要采用广泛使用的，有许多人进行研究与维护的协议。采用TLS就是基于这点考虑。
在我上面的方案中，提到了明文vmess的鉴权，和vmess的加密层。个人认为这里也需要贯彻上面的指导思想，不要自信的进行自创。我想是否可以参考wireguard的身份验证流程、加密方法。在它的基础上做出TCP传输支持、AES-GCM系列加密支持，甚至兼容wireguard的虚拟网卡驱动，直接实现VPN级别的代理。
借鉴该方案的实现可以免去新设计协议的大量安全论证工作，避免潜在的安全风险。即使出了漏洞，wireguard现在是Linux内核代码了，会有很多使用、研究、维护的人，到时候可以一并跟着修复。

[ActiveIce]

此issue过长，建议关闭。
我希望新开issue的讨论是带着方案或实现来的。当前存在何种问题，何种新方案有何优点，解决/规避了上述问题。讨论方案和在issue提出bug是一回事，得有个大体的格式，不然整体效率就会被拉低。
还是那句话，用A+代替A，B+代替B，这样的讨论才能推进思考。
大家莫光说缺点了，多说点方案吧，最好是能兼容多种需求的整体性方案，球球了。

[rprx]

我想补充一点刚想到的。没有永远安全、绝对安全的协议，我们需要采用广泛使用的，有许多人进行研究与维护的协议。采用TLS就是基于这点考虑。

这一点我已经重复了很多遍。

此issue过长，建议关闭。
我希望新开issue的讨论是带着方案或实现来的。当前存在何种问题，何种新方案有何优点，解决/规避了上述问题。讨论方案和在issue提出bug是一回事，得有个大体的格式，不然整体效率就会被拉低。
还是那句话，用A+代替A，B+代替B，这样的讨论才能推进思考。
大家莫光说缺点了，多说点方案吧，最好是能兼容多种需求的整体性方案，球球了。

正如我说的，晚些时候会重开一个issue。

[Kylejustknows]

1， 底层协议的难点不在于加密，（数据部分加密不管是直接使用TLS1.3还是使用TLS认证过的那些加密算法，都很容易实现）； 难点在于身份认证段，如何添加身份认证后还能避免攻击和嗅探；
2，TLS的使用范围有限，需要域名、外网链接、证书等，而V2Ray作为一种流量转发工具，可以用来制作很多复杂的内网间和跨域的流量中转通道。如果纯粹为了翻墙，去试试Trojan吧纯TLS，但如果一旦你开始需要更复杂的多层内部流量中转机制，还得回到自有协议的V2ray上来。

其实，新协议不影响v2ray的“流量转发工具作用”
为了翻墙，是基于tls的新协议
不为了翻墙又需要身份认证等，去掉tls即可
而v2ray原有的路由等机制可以复用
这也是我比较想给v2ray引入一种这样的协议的原因

你的意思是，把（身份握手+数据）都封装在TLS加密之下？
那太简单了 :D，用nginx或者caddy随便开一个“网页版代理服务器”，强制只能https+tls1.3访问就行。看起来所有“身份验证+数据包”都封装在tls加密之下，非常完美。但我保证访问youtube的话，5分钟以内服务器就被墙掉。哈哈哈哈墙其实很厉害的。

1，加密不是难点，tls使用的加密算法都是公开的大家都可以使用。tls的精华是让两个互相不信任的双方能安全沟通。而v2ray则允许大家两边都预设好密码，用tls其实大材小用。

2，tls1.3会导致翻墙特征更明显。因为网络上99.99%的tls1.3流量都是用来访问网站的，突然冒出一段新的tls1.3链接，探测服务器地址发现不是网站，那就更可疑了。一旦v2ray走上tls道路，那就逼着所有v2ray用户都必须搞域名和架设网站了。（那还不如现在无特征vmess呢，用户也能自由组合其它服务使用，自取其用。用户自己搞出的v2ray的新玩法自己偷偷使用不在论坛里说的非常多，比如说我。墙搞不清我那些流量是干嘛的。而有特征的tls1.3，哪怕再融入其他协议下，只要被探测出特征就可疑了）

3，你想要的协议，就很类似于我的Caddy+V2ray打包 (为了方便部署，我曾经把Caddy和V2ray打包了。Caddy来握手TLS协议、域名证书获取等等；而V2在后台进行freedom），前提也是已有正规网站的tls流量来迷惑墙。

==================

我的意思是，对于高端一些的用户来说，更需要的是一个“流量无特征”的工具。

就是：如果我想让它看起来像是TLS1.3，我就把它封在TLS协议里；如果我想让它看起来好像我在用ftp上传和下载几个大的.zip文件，我就把它封在ftp协议里。

而一旦开始使用有特征的协议后，能被使用的方法就锁定了。比如使用TLS，你就只能用它来模拟访问网站，其他的使用方法都更容易暴露了。

[rprx]

@Kylejustknows

大材小用

并不存在

我现在不反对 VMess 2

其余的等下补充

[klzgrad]

我不是“有人”，如果不知道我是谁，可以去查一下。我的回复👎竟然是👍的两倍，网络真是健忘的，看来有必要发一个《GFW技术评论》的迷你社论在这里：

顶楼的提议当然在技术上是进步的，TLS在技术上比土制协议更先进，不然我也不会在自己的实验项目里走这个方向。但是很多人的思维惯性是技术决定论，没有搞清战略态势。

不知道是不是钢4引用的名言，“业余玩家谈论战术，职业军人研究后勤”。决定这个对抗性研究斗争成败的很大因素，在于后勤。在翻墙技术研究里的后勤就是人力和资金。从人力和资金来看，国家机构都占有压倒性的优势。这个时候去把技术力量集中于打造极少几个完美方案，就如同井冈山反围剿的时候与中央军打阵地战正面冲锋。不是败于技术强度，而是败于后勤。实际的例子，二十世纪初的自由门，一月一换协议，结果被上交等团队集火。美国军方、国务院资助的匿名网络的技术顶峰Tor，照样被集火。最近谷歌资助的Outline也好不到哪去。

而战略态势是什么？研究“反翻墙”的不是一个匿名机构，其实很明确，工信部安管中心，国家应急响应中心，高校实验室，网络安全公司。而且他们也不是专门要与翻墙群众过不去，国安基础设施（与PRISM对标），反病毒和botnet，防止境外有害信息传播（宣传口，查封网站），网络信道的垄断权（通管局数字主权，抓卖代理的人），优先级的最后才是把大家的自用梯子给封了。只是恰好加密信道技术具有共通性，翻墙能用的加密信道botnet也会去用。

有这么多对手，分到反翻墙上面的人力物力是排到最末的。实际情况中比较可能的研究翻墙技术的主力就是高校的研究生，研究过程就是一个自然科学基金委发了资金，要在有限的时间内出一个成果，导师要评职称，学生要毕业。这样的后果就是，没有人在这里跟你经年累月地耗。像v2ray这种项目，光用户配置的协议组合就要十种八种，我自用已经烦死了，让研究生去分析，就要烦爆了。这个时候你把协议组合减少成一种，去引诱对方成立专项工作组，不是自送人头吗？

我有什么证据证明反翻墙技术研究的混乱？从有墙的时代开始直到前几年，你可以在21和25端口上跑一个明文的HTTP/1.1代理而不被封。我从来没有公开这个事情，因为这个漏洞太容易补，但就从这里就能看出问题了。另外一个后勤上的例子，比如现在流行用机器学习，深度学习去做流量分类，但由于base rate fallacy造成非实验室条件下误报率过高，以及推理网络开销巨大，基本上没有可能落地到在线防控管理的系统里，也许可以做一些离线分析。这种情况下什么准确率99%都没有任何意义，如果有意义只能说明协议里面有肉眼能看出来、三行代码能测出来的特征，就不需要学什么学了。

所以在这种战略态势下，v2ray所代表的范式就是一个辩证的思想，游击战、人民战争，造成反翻墙研究者没有明确可控的研究对象，打掉一个协议，出来十个协议，越打越多，而不是越打越少。这个时候v2ray的弱点就辩证地转变成它的长处，没有一个中心管理团队，没有协议的顶层设计，各种协议组合之间也没有优劣之分，也就没有研究的头绪。现状已经自然而然地形成到这样，具有了它内在的合理性。你可以在技术上类比强度和韧度的区别，往TLS深处研究可以提高强度，但是缺少了外围根据地，这样是没有什么韧性的。

而且告诉你，TLS也没有你想象的那么好。这个协议本身会散发出大量信息。而且由于使用证书的原因，在地址上缩小了搜索空间。

上面我比较夸张，但实际上我的推荐也不是完全不用TLS，现在不是已经用了吗？的确可以探索。关键是不要TLS为理由来把其他所有协议组合提供的“外围根据地”、韧性、或者叫战略纵深给取消掉。

[Kylejustknows]

所以在这种战略态势下，v2ray所代表的范式就是一个辩证的思想，游击战、人民战争，造成反翻墙研究者没有明确可控的研究对象，打掉一个协议，出来十个协议，越打越多，而不是越打越少。这个时候v2ray的弱点就辩证地转变成它的长处，没有一个中心管理团队，没有协议的顶层设计，各种协议组合之间也没有优劣之分，也就没有研究的头绪。现状已经自然而然地形成到这样，具有了它内在的合理性。你可以在技术上类比强度和韧度的区别，往TLS深处研究可以提高强度，但是缺少了外围根据地，这样是没有什么韧性的。

而且告诉你，TLS也没有你想象的那么好。这个协议本身会散发出大量信息。而且由于使用证书的原因，在地址上缩小了搜索空间。

上面我比较夸张，但实际上我的推荐也不是完全不用TLS，现在不是已经用了吗？的确可以探索。关键是不要TLS为理由来把其他所有协议组合提供的“外围根据地”、韧性、或者叫战略纵深给取消掉。

哎呀，说的太好了。和我想法一样。只要Vmess自身保持”无特征“，然后用户想用TLS封装就可以自己封成TLS，用户也可以封装成模拟下载压缩文件啊，也可以模拟远程视频会议啊。。。。遍地开花才最好。把底层协议就固定成TLS，反而是开倒车了。

[ActiveIce]

分散特征的方法也是有道理的。我担心的是，会不会历史重演，一月一换协议还是被集火，或者就像现在这样，v2那么多协议，一个个被攻破。
服务器端尚且编译就能运行，客户端要跨平台，还要能兼容超多新协议，感觉开发成本高起来了。
当然，如果全部人用TLS，最后TLS也用不了了，那也巨难受啊。。。
有没有什么比较可行的实施方案？

[rprx]

@ActiveIce

我认为你可以重新开一个issue，现在我并没有心情去讨论新协议的设计。

总体思路是阉割vmess：

1.保留鉴权功能
2.可选的加密功能
3.加上可扩展的混淆方案
4.去掉其它多余的功能/特性

以及保持与现有v2ray其它组件的兼容（其实就只是另一个协议而已，该协议建议结合tls底层传输方式使用，但也可以不结合），以便复用现有的路由等功能。

关于 TLS 指纹，可以参考我开的另一个issue。

希望这是在短期就能实现的可行的解决方案，毕竟vmess2不知何时才能设计出来。

但在新issue中要明确哪些讨论是离题的，防止再次出现这里的情况。

[rprx]

@klzgrad
@Kylejustknows

从大局来看，我认为你们说得有道理：各种土制协议，无论混淆/安全性/性能如何，的确牵制敌方火力。

不过我也在回复别人时提到了，我之前的思路是 what's good for v2ray
现在各种裸协议都过得不太好，而vmess + wss却仍然相对坚挺
这种情况下，不让v2ray转向tls，我认为它会成为某种程度上的牺牲品，为队友吸引火力
当然，对已经基于 TLS 的其它方案，却是好事
vmess等土制协议的韧性，并不是自身的，而是分散火力，防止集火 TLS
从这个意义上来说，我也支持各种基于 TCP 的土制协议继续放烟雾弹

其实 TLS 在这里有很多角色，其中之一是安全性。那么，设计 VMess 2 时，是否可以先参考一些 TLSv1.3 已有的最佳实践（或者说，简化它的流程、去掉它的特征），然后再结合身份鉴权、混淆等其它功能？这样安全性可能会更高一些。这是对 VMess 2 的想法。

[isArtJay]

所以在这种战略态势下，v2ray所代表的范式就是一个辩证的思想，游击战、人民战争，造成反翻墙研究者没有明确可控的研究对象，打掉一个协议，出来十个协议，越打越多，而不是越打越少。

赞同

[1265578519]

https://github.com/v2ray/discussion/issues/558#issuecomment-637069133
楼主能帮帮我吗？

[Kylejustknows]

分散特征的方法也是有道理的。我担心的是，会不会历史重演，一月一换协议还是被集火，或者就像现在这样，v2那么多协议，一个个被攻破。

只要vmess这个底层协议没有被找到漏洞“特征”（比如刚刚出的那个被探测的bug），就不存在一个个被攻破的情况。
某个伪装被嗅探识别了，并不影响另外一个伪装，只要它们的底层是“无特征”的，就无法批量针对。
用现有的“无特征”的协议，制作一个伪装，比开创一个新的协议，难度要低很多。vmess协议的价值就在这。

翻墙技术这么多年进化至今，“无特征”是最大的难点。加密不是那么重要，因为哪怕最老旧的RC4加密，破解一次都要用海量的资源。使用哪种加密协议、是否外套一层TLS等等，这些都是应用级别的花边。

这种情况下，不让v2ray转向tls，我认为它会成为某种程度上的牺牲品，为队友吸引火力
当然，对已经基于 TLS 的其它方案，却是好事

v2ray的ws+tls+web，是完全版的tls，所有数据都在tls加密之下，没有漏洞。并且将来tls升级比如说tls1.4了，只要升级网页服务器这个“外壳”就行了。
有一种观念，Trojan(只有tls访问模拟)，只是一个精简版的v2ray而已，我个人是赞同的。

V2ray是台式机电脑，可以用来上网、玩游戏、写代码、搞设计，做几乎所有事情。
而Trojan是一台xbox，只能用来玩游戏。
但你说，我们把电脑做成只能玩游戏就行了，否则会玩不过纯游戏机。这个我是不赞同的。

vmess等土制协议

我不太赞成这个说法，因为至今我知道的“无特征“、”无法被嗅探“的协议，全世界只有SS和Vmess这两个。所以它们不能算是土制协议，而几乎是行业标准了。我们并没有那么多的”土制协议“。

设计 VMess 2 时，是否可以先参考一些 TLSv1.3 已有的最佳实践（或者说，简化它的流程、去掉它的特征）然后再结合身份鉴权、混淆等其它功能？

使用TLS1.3承认的加密算法就行了。因为TLS1.3中包含的绝大部分功能，是vmess压根都用不到的 （沟通证书签发机构、证书处理、数字签名等等）。 而你说的”结合身份认证、混淆、去掉特征“，这几个特点能同时实现，是翻墙界无数大牛多年研究至今仍未完全解决的世界级难题，没有那么容易。

[rprx]

@Kylejustknows

晚上好。

无特征是最大的难点

认同。否则我也不会说始终在创造特征，这真的很难实现。

v2ray的ws+tls+web，是完全版的tls，所有数据都在tls加密之下，没有漏洞。

我知道是完全基于真正的 TLS 而不只是伪装。

事实上，我正在使用 socks5 to vmess + ws tls1.3 + cloudflare + ws tls1.3 + nginx + ws + vmess to freedom + tor 网络登录这个由 protonmail 注册的 github 账号，我也在服务端的 v2ray 配置了主动式 DoH + 拦截式 DoH（但 tor 网络下不会用到）。同时，我的 nginx 的 443 端口只接受来自 cloudflare ip 段的 tls1.3 连接，并在 stream 段预读取 sni 验证域名正确后才通过 unix socket upstream 到真实的 server 段，在那里完成 tls1.3（开启了earlydata）解包、路径分流后才将 ws 转发给 v2ray。这样做可以保证 443 端口的请求只放行 cloudflare，否则对方连证书公钥都拿不到，更不会知道我在服务器上部署的域名（不管是端口扫描还是带域名的定向探测）。大概只有我这样配置 nginx。当然，如有必要，我还会同时开启和 cloudflare 的 TLS 双向认证。

我说上面这些话的目的，只是为了证明我不是小白，并且有实践，无其它指向。

并且将来tls升级比如说tls1.4了，只要升级网页服务器这个“外壳”就行了。

如果你看了我的发言，你会发现我和你持相同的观点。

有一种观念，Trojan(只有tls访问模拟)，只是一个精简版的v2ray而已，我个人是赞同的。

如果我没记错，trojan 需要直接将自己暴露出去，我个人不喜欢这样。

为了避免这个回复太长，我会先 comment，然后另起回复。

[rprx]

@Kylejustknows

V2ray是台式机电脑，可以用来上网、玩游戏、写代码、搞设计，做几乎所有事情。
而Trojan是一台xbox，只能用来玩游戏。
但你说，我们把电脑做成只能玩游戏就行了，否则会玩不过纯游戏机。这个我是不赞同的。

你说的有一定道理。

不过，我个人并没有把 v2ray 用于其它用途，我不知道多少人是这样。比如，如果需要内网穿透，我会选择 frp。当然，我在本 issue 中的所有观点，完全是基于 fq 用途。如果考虑到其它用途，则是另一种情况了。

我不太赞成这个说法，因为至今我知道的“无特征“、”无法被嗅探“的协议，全世界只有SS和Vmess这两个。所以它们不能算是土制协议，而几乎是行业标准了。我们并没有那么多的”土制协议“。

至少今天无法认同。就像我说过的：TLS 是什么时候有 AEAD 加密方式的？正式发布于 2012 年。SS 是什么时候才进行此项改进的？2017 年。而 VMess 是什么时候？not yet。

当然，SS 和 VMess 的确起到了带头作用，并且相对更完善。

使用TLS1.3承认的加密算法就行了。因为TLS1.3中包含的绝大部分功能，是vmess压根都用不到的 （沟通证书签发机构、证书处理、数字签名等等）。 而你说的”结合身份认证、混淆、去掉特征“，这几个特点能同时实现，是翻墙界无数大牛多年研究至今仍未完全解决的世界级难题，没有那么容易。

你阅读过快了，我说的是去掉 tls1.3 的特征。

而关于简化 tls1.3，已经有人在这么做了：https://github.com/v2ray/v2ray-core/issues/2541#issuecomment-638118861

[nametoolong]

@Kylejustknows

我不太赞成这个说法，因为至今我知道的“无特征“、”无法被嗅探“的协议，全世界只有SS和Vmess这两个。所以它们不能算是土制协议，而几乎是行业标准了。我们并没有那么多的”土制协议“。

Lantern has lampshade, Tor has obfs4, and Brook, Geph and MassBrowser all have their 'unidentifiable' protocols. The author of Geph even addressed VMess as 'working behind closed doors'. All of these protocols (including Shadowsocks and VMess) are identifiable to some extent: Iran once blocked obfs4 based on inter-arrival timing features, while my corporate network blocks VMess with some magic.

We all know obfuscation itself is also a feature: SSR traffic can easily be distinguished because it is so random, although it may never be a way to perform 'precise probes'. So there is significance in making a lot of home-brew protocols. We need a lot of different features to cover the entire space of features (so classifiers will let some go through as soon as it starts blocking some), not exactly one that is hard to detect.

[Kylejustknows]

Lantern has lampshade, Tor has obfs4, and Brook, Geph and MassBrowser all have their 'unidentifiable' protocols.

Well, good sum up. Yea I forgot obfs4 and lampshade, they are seasoned protocols as well.

All of these protocols (including Shadowsocks and VMess) are identifiable to some extent.

Yep, that's why I said in my comment that making a stream unidentifiable is a world-class difficult problem.
I am wondering: in theory, mathematically, can a truly unidentifiable protocol ever be made?

can easily be distinguished because it is so random

Nowadays, nearly all the traffic over the internet is somehow "compressed" (gzip/h264 etc.) behind some sort of encryption(TLS etc.). If you understand entropy then you know all these data streams would look extremely random to the middle-man.

Randomness is not a weakness. There must be something else in SSR has been undermined.

[nametoolong]

in theory, mathematically, can a truly unidentifiable protocol ever be made?

Looks-like-nothing is possible, but I believe it is not the case for 'truly unidentifiable'. What the classifier does is separate some protocols from others. Maybe it cannot distinguish between Shadowsocks and VMess traffic, but as long as the collateral damage is negligible, it can use more agressive strategies to block a whole group of looks-like-nothing protocols. See Detecting Probe-resistant Proxies on NDSS 2020 for some behavioral fingerprints.

This is beyond the scope of cryptography though. It is not very hard for a protocol to achieve computational indistinguishablility.

There must be something else in SSR has been undermined.

Randomness is not a weakness. Improper randomization of packet length is. After the discontinuation of SSR, SSRR proposed auth_chain_b, auth_chain_c and a bunch of other auth_chains. Nevertheless, a uniformly random distribution of packet length is extremely rare so some ISP DPIs blocked them outright.

Here we see, uniformly random packet length is an issue. The absence of packet length obfuscation is another. Which strategy should we make when performing packet length obfuscation? This question has bothered NaïveProxy for some time.

[Kylejustknows]

Randomness is not a weakness. Improper randomization of packet length is. After the discontinuation of SSR, SSRR proposed auth_chain_b, auth_chain_c and a bunch of other auth_chains.
Here we see, uniformly random packet length is an issue. The absence of packet length obfuscation is another

I did have some proposals in my mind, but I am glad to see that smarter people are working on some solutions.

This question has bothered NaïveProxy for some time.

What an interesting research topic! You keep bringing me new subjects to read. I guess this breaks down the issue into only two solutions: 1, an obfs algorithm that emulates the packets' pattern of actual protocols (TLS, Bittorrent, Teamviewer, Bitcoin etc.) really well; 2, Hide behind an existing application eg. WebSocket.

Now I am very keen to give naiveproxy a try.

[darhwa]

Now I am very keen to give naiveproxy a try.

Spoiler: Naiveproxy, with or without padding enabled, is easily detectable under packet length analysis.

So, please give up the idea that TLS itself is already the silver bullet. If somebody advocates this opinion, it only reveals that he knows little about the real situation.

[Kylejustknows]

Spoiler: Naiveproxy, with or without padding enabled, is easily detectable under packet length analysis.

So, please give up the idea that TLS itself is already the silver bullet. If somebody advocates this opinion, it only reveals that he knows little about the real situation.

I believe NaiveProxy emulates "Chrome TLS handshakes" really well since it uses chromium network stack, and the developer did some good research.(Let me know if I am wrong. I also wish V2ray should do a similar traffic analysis as when V2ray client connects to the https+ws server)

But the NaiveProxy it lacks strong data obfuscation like vmess/ss so the pattern may show up when users access youtube/twitter. (I am not sure. Padding + TLS1.3 seems strong enough to me. But there are people smarter than me working at GFW so..)

[nametoolong]

@Kylejustknows
It was @darhwa who found out that payload padding in NaïveProxy is not even working.

[est]

我担心的是，会不会历史重演，一月一换协议还是被集火，或者就像现在这样，v2那么多协议，一个个被攻破。

来说下我的设想：协议不仅要每次安装随机换一个，每天定时换一个，甚至 accept() 的时候就要随机换一个。发现有scanner来嗅探连接就直接封IP，然后通知客户端立刻PPPoE重新换MAC拨号。

related: https://github.com/v2ray/discussion/issues/711

[Kylejustknows]

我担心的是，会不会历史重演，一月一换协议还是被集火，或者就像现在这样，v2那么多协议，一个个被攻破。

来说下我的设想：协议不仅要每次安装随机换一个，每天定时换一个，甚至 accept() 的时候就要随机换一个。发现有scanner来嗅探连接就直接封IP，然后通知客户端立刻PPPoE重新换MAC拨号。

数据包长度(或其他特性), 每小时一换/每天一换, 这就是特征, 肯定会被封. 因为网上正常的服务器没有这样特性的。

数据包太固定, 是特征; 数据包太随机, 也是明显特征.

上面贴的 NaïveProxy 的流量分析, 可以让我们窥探一下真正的一个TLS握手的数据包"模样", 你可以看出, 协议都是有自己复杂的特征"指纹"的, 仅仅数据包的大小这一个层面, 各个协议、使用不同的客户端，都会产生特有的统计纹路.

这些跟PPPoE重新拨号换IP等没有联系。GFW直接封掉你服务器的IP，跟客户端没关系。

[est]

数据包长度(或其他特性), 每小时一换/每天一换, 这就是特征, 肯定会被封. 因为网上正常的服务器没有这样特性的。

最后半句是你脑补的还是有确切证据的？

只要流量不规范，就封服务器 IP，通管局就不怕投诉电话被打爆？😂😂😂😂

其实说到底，被封只有一个原因。那就是使用人数太多，被立了专项攻关。

[Kylejustknows]

最后半句是你脑补的还是有确切证据的？

哎，因为网上多数“合法的”服务器，基本都是一个主机单纯提供一个服务（网页服务器、流媒体服务器、游戏服务器等等），它们的数据包，统计起来都是常年很有规律的。

只要流量不规范，就封服务器 IP，通管局就不怕投诉电话被打爆？

它们真不怕。大概一两年前我自己写的一个只有几十行代码的管理小工具，服务端和客户端TCP连接后传递一些命令和二进制（你就当是个简单的聊天软件吧），测试时有次我把服务端放在香港VPS上，结果运行了几分钟就被断了。当出现墙不认识的可疑流量，它一不高兴就会随机地reset你，作为个人用户我猜哪怕我打电话投诉，“通管局”或者中国电信对我的情况也一无所知，因为这事发生在国际网关并且是全自动的。

[henrypijames]

只要流量不规范，就封服务器 IP，通管局就不怕投诉电话被打爆？😂😂😂😂

At least it will trigger a closer look, which could be automatic (like sniffing). And depending on the result of the closer look, it could be blocked temporarily (say, 12 hours, or 72). I have experience this myself as well (and I switched systems after the second automatic temporary block).

We are the 0.1% of all Internet users. If a strike against us carries 10x collateral damage, that's totally acceptable for the wall. In fact, even a 100x collateral damage can be swallowed if need be.

其实说到底，被封只有一个原因。那就是使用人数太多，被立了专项攻关。

Again, that is not true. There are people of "suspect class" (to borrow a legal term) who are of high interest, and whatever they use will be targeted, even if there are only very few people using it.

Just because you can only image one thing doesn't mean it's the only thing that exists. And just because you can't imagine how something could be done doesn't mean it can't be.

[est]

大概一两年前我自己写的一个只有几十行代码的管理小工具，服务端和客户端TCP连接后传递一些命令和二进制（你就当是个简单的聊天软件吧），测试时有次我把服务端放在香港VPS上，结果运行了几分钟就被断了。当出现墙不认识的可疑流量，它一不高兴就会随机地reset你

老哥，你这个可以复现么。 莫非是阿里 vps。。。按照我的经验，reset 针对单个服务器端口，你换个端口试试呢？

it could be blocked temporarily (say, 12 hours, or 72). I have experience this myself as well (and I switched systems after the second automatic temporary block).

Are you using VPS providers like bwh or linode? Yet changing system is good idea, change protocol is terrible idea. Gasp!

Again, that is not true

Thanks for your opinion. Developers have many home-made protocols survived over the years pretty well, I knew few people are doing this. Do you have any proof that protocols with small user base gets blocked?

[Kylejustknows]

老哥，你这个可以复现么。 莫非是阿里 vps。。。按照我的经验，reset 针对单个服务器端口，你换个端口试试呢？

换一个端口，肯定是我最先做的事情啦，新端口坚持几分钟就又被封了。这事很久了，仔细想想不止一两年了（时间过得真快啊），长城是好几个进化之前的了，不代表现在的情况。
当时这事勾起了我的食欲，随后测试了一堆类似于x11啊softether啊各种大众、小众、加密、不加密的协议，从此入坑，开始长期关注翻墙界。

[henrypijames]

Are you using VPS providers like bwh or linode?

It was a VPS provider, but not a famous one.

Yet changing system is good idea, change protocol is terrible idea. Gasp!

I have nothing against changing your system, or your protocol - if something doesn't work anymore, you should change it, duh. I am against generating a lot of protocols - because it is guaranteed to be unsafe. We need more than one protocol, but we shouldn't have dozens of them, and we especially shouldn't try to have them generated by an algorithm.

The problem with your idea is not that it envisions many protocols - it's that they would have to be related with each other (because otherwise they couldn't be generated automatically). Giving your opponent many unrelated protocols to crack is good - they busy him up; giving him many related protocols to crack is bad - he will be able to find the relation and use it as a hint to crack them all together faster than if he only had a single protocol and no such hint.

Do you have any proof that protocols with small user base gets blocked?

I have no proof I'm willing to share publicly. These people are already endangered to begin with.

[wenjinlibug]

@Kylejustknows 個人覺得我們是不是應該換一種戰略思維？畢竟對於翻墻方來説面對的是完全不成比例的國家資源項目，對於這種不能正面對抗的對手，除了像你所説的讓各種土製協議遍地開花來分散對手的資源外，真正有效的方法我覺得是盡可能的以小博大讓對方陷入糾結，即讓某種協議的封禁連帶造成不可預估的巨大經濟損失，使墻在明知道存在翻墻行爲的情況下也不敢輕舉妄動，因此我認爲徹底混進標準https流量裏的協議才是最有效的。

[Kylejustknows]

@Kylejustknows 個人覺得我們是不是應該換一種戰略思維？畢竟對於翻墻方來説面對的是完全不成比例的國家資源項目，對於這種不能正面對抗的對手，除了像你所説的讓各種土製協議遍地開花來分散對手的資源外，真正有效的方法我覺得是盡可能的以小博大讓對方陷入糾結，即讓某種協議的封禁連帶造成不可預估的巨大經濟損失，使墻在明知道存在翻墻行爲的情況下也不敢輕舉妄動，因此我認爲徹底混進標準https流量裏的協議才是最有效的。

早年有人提出过路由层面的翻墙伪装项目。 就是从中国这边看起来用户在访问微软的服务器，IP什么的都是微软的，但是流量包到达美国的光纤入口路由后，路由能识别出数据包内隐藏的内容，然后把用户数据转发到真正想要访问的服务器。这项目需要网络底层和国家层面的支持。只是后来不知道怎样了。

[wenjinlibug]

@Kylejustknows 個人覺得我們是不是應該換一種戰略思維？畢竟對於翻墻方來説面對的是完全不成比例的國家資源項目，對於這種不能正面對抗的對手，除了像你所説的讓各種土製協議遍地開花來分散對手的資源外，真正有效的方法我覺得是盡可能的以小博大讓對方陷入糾結，即讓某種協議的封禁連帶造成不可預估的巨大經濟損失，使墻在明知道存在翻墻行爲的情況下也不敢輕舉妄動，因此我認爲徹底混進標準https流量裏的協議才是最有效的。

早年有人提出过路由层面的翻墙伪装项目。 就是从中国这边看起来用户在访问微软的服务器，IP什么的都是微软的，但是流量包到达美国的光纤入口路由后，路由能识别出数据包内隐藏的内容，然后把用户数据转发到真正想要访问的服务器。这项目需要网络底层和国家层面的支持。只是后来不知道怎样了。

早年推不動是正常，今年就不一樣了，如果有議員願意推動類似議案並且不是和微軟之類美國本土企業綁定而是和中共在美宣傳機構的流量綁定、比如抖音，估計獲得通過的可能很大，畢竟改動路由的支出很低，而且不會觸及政治敏感的言論自由同時可以抑制中共在美的宣傳活動。

[limaofu]

任何协议都会有特征，要明白什么样的流量才能过境，当然是Https了。直接基于tcp的协议设计得再好也是鸡累，

[Kylejustknows]

任何协议都会有特征，要明白什么样的流量才能过境，当然是Https了。直接基于tcp的协议设计得再好也是鸡累，

1是如果你对着海外一个ip访问了几个GB的纯https，这本身就高疑。2是对https进行流量特征分析，墙已经能准确判断出你访问的真实网站。

[github-actions[bot]]

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days

[rprx]

如今 在一定程度上混淆流量以防止基于机器学习的流量分类 已经成为了必须要做的事情，我们需要噪音。

[rprx]

即持续不断的噪音，并将数据嵌入其中、消除流量时序特征，什么都分析不出来。