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

[RPRX]

2020-06-20 更新：

[New Protocol] VLESS ALPHA

---

2020-06-05 更新：

更详细的方案：非可信通路 与 可信通路（VMore and VLess），含 VLess 具体设计方案 #2547

---

基于 TCP 的 VMess 已不再安全：#2523，此 issue 中也有一些与本 issue 相关的预探讨

尚不了解 TLS 的请先看 https://zh.wikipedia.org/zh-cn/TLS

什么是 “基于 TLS 设计” ？

指的是将 TLS 作为新协议的必要底层传输方式，但千万不要理解成要改造 TLS 本身

不一定是直接基于 TLS，可以选择性加一层 Websocket/Http2/Http3

相对于现在的方案，新协议有什么优点？

与时俱进的安全性：大多数安全性问题已由 TLSv1.3 解决，且 TLS 不会止步 1.3 —— 每当有新的潜在安全性问题出现时，TLS 将会升级，而新协议几乎无需做出改变就可以从中受益。
此外，服务端都有路径分流，可以彻底解决被主动探测的问题。

简单与纯粹：协议本身只需设计身份认证等功能，以及在一定程度上混淆流量以防止基于机器学习的流量分类（所以不能直接用明文/Socks5）。而不用像现在的 VMess 一样绞尽脑汁防攻击、额外加密。比起来重新设计 VMess，设计这个新协议会简单很多。

长期隐蔽：如今互联网上 TLS 已成为主流，新协议的流量可以混于其中，而不像裸 VMess、SS 等特立独行 —— 长期以来这些协议无论怎么设计/修复，始终是在“创造特征”，而墙早已学会了识别特征并封锁。继续这样你来我往毫无意义，远不如直接用 TLS 作底层，相对一劳永逸。

自己在 TCP 上设计协议，注重加密和防各种攻击是少不了的（这部分性能始终要损失），而 TLSv1.3 本来就是一种最佳实践（如必须的 AEAD 加密改进），所以不如直接用 TLS 以减少特征、减轻心智负担。

为什么当初没有直接这样设计？

VMess 出现于 2015 年（Shadowsocks 则更早），那时互联网上 TLS 并不普及，TLSv1.3 也未正式推出。但现在是 2020 年，TLS 已成为主流，TLSv1.3 也足够安全并被广泛应用了，所以我认为目前及以后套 TLS 才是最佳选择与长久之计。

在新协议被设计出来之前，尚有安全的 VMess+WSS 可用，只是多余的特性会损失些性能。
当然，VMess+WSS 已经是多数选择了，也证明了基于 TLS 的可靠性。
可以先关闭 VMess 自带加密 v2ray/discussion#686

其它一些话

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

2020-06-02 更新：

对于 VMess 2 的设计，不反对，可以同时进行
有人觉得基于纯 TCP/UDP 的协议也安全可靠，那想用就用

希望看到更多基于 TLS 的协议（或者说不同的流量混淆方案
其它地方已经有类似的方案，我相信基于 TLS 设计协议正在成为主流方向

V2Ray ≠ VMess，V2Ray 的初衷应该是与时俱进，而不是死守一种方案
毕竟，我们为了 fq 而设计的这些土制协议，有非基于纯 TCP 不可的原因吗？

[iseki0]

个人认为有极大必要加入 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，以及实现 v2ray/discussion#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

[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: v2ray/discussion#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]

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]

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