-
Notifications
You must be signed in to change notification settings - Fork 9k
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
[Feature Request] 次世代方案:设计一个基于 TLS 的简单协议(VLess) #2526
Comments
个人认为有极大必要加入 ws/http2 层,否则通讯时序和可能的数据包大小或许会成为另外的特征 |
有必要,供用户选择 |
胜读十年书,确实如此,大家都在把精力放在创造特征上 |
是不是在設計之初就應該考慮支持ESNI ? |
ESNI 会在适当的时候由 TLS 实现(指目前 ESNI 非常小众 |
其它地方的确已经有类似的方案。 |
現在是沒什麼用,只是爲未來正式發布後做準備 |
其实这个是交给 Golang 的 TLS 库来实现的,无需担心不支持 |
重新設計的協議還有必要局限於Golang 嗎?還有必要局限於v2ray 嗎? |
关于这一点,我认为v2ray的其它部分还可以一用 重开的话我倾向于rust,以及实现 v2ray/discussion#706 看有没有大佬愿意接手,我还很年轻,并不想花更多时间在这件事上 但我向为这个项目和类似项目付出时间的所有人致敬 |
身份认证功能,caddy forwardproxy自带。而且还完美防主动探测。 forwardproxy的作者就是uTLS的作者,Sergey Frolov |
@yeahwu 通过v2ray来用,每次请求自动发认证头,就不需要浏览器支持了。 |
从长远来看,我的观点是 综上看,最近的解决方法是 然后再慢慢弄新的 |
someone please translate this thread to english, google translate is the worst. |
try deepl @itshaadi |
我旗帜鲜明地反对在v2ray里面直接使用TLS。不要因为受了一点挫折,就感觉要拉倒不干了。 v2ray最大的力量不在于它的安全攻防技术在战术上最先进,而在于它起了作用发动群众搞大量土制协议,扩大了安全战略纵深,使得对抗性研究因为目标繁杂而进展困难。 如果所有土制协议都收敛到TLS上,那对抗性研究的范围就大为收窄,难度就大大下降了。所以v2ray协议设计越丑陋,其实就越有韧性。 |
这么多年了,也就出了两只手数的清的比较有名的协议,说明大家精力都是有限的,还是得投入到目标明确的数量少的事物当中去,把有限的精力用在刀刃上 |
无法认同你的观点: 不如你跳出思维定式:新土制协议们为什么非要基于纯 TCP 呢?基于 TLS 的百花齐放不是更好吗? 按照目前新土制协议的趋势,TLS 正在取代纯 TCP 成为新的默认底层 不过,如果大佬们时间充裕,不反对同时设计基于纯 TCP 的 VMess 2 |
基本认同且可行 |
一直在主力使用V2ray,但并不是Go开发者(是个写Java的),想略抒愚见。最近项目中用到了谷歌的GRPC,它是基于Protobuf的,虽然我不太清楚代理底层到底是那种工作机制,但是我想vmess或许可以迁移到GRPC上,这个框架首先支持Go,其次支持TLS认证和加密,可以使用自签CA进行服务器与客户端的双向认证。目前在我手头的项目中表现得不错,但是生成证书和配置上对于非程序员来说可能会比较麻烦,而且如果使用正常网站打掩护,那么自签证书肯定是不太行。但是单方面使用服务器证书认证和加密也完全可以做到,考虑vmess本身也有鉴权,不用双向也行。双向验证在我这儿完全就是因为不想在应用内再做鉴权,所以直接用GRPC提供的机制阻止非认证客户端使用服务。 因为一直没有接触过代理的开发,所以不知道这样的想法行不行。另外关于自制协议,我觉得一个家用路由器都可以轻易的掐断或放行某一种游戏(@华硕)的连接,那GFW对于土制协议我想更是轻而易举。固然数量足够多且不同的土制协议会让GFW看花了眼,但是不排除在这种情况下GFW会选择性的根据流量大小开启类似白名单之类的机制,小额流量可以不管,如果某一个特征的流量达到一定程度,且不认识这种特征,那么就掐断它,我觉得这使得土制协议非常脆弱。就目前来说可能还是混在某种大量且重要的协议中(例如TLS)比较好吧。 |
结尾处是指vmess,并不是说不推荐其他代理软件自创协议(微博PTSD)。本质上说一旦失去了多样性,尽管从现实上来说隐藏在大流量中很稳,可一旦要找到突破口,那么没有第二种协议就是一个非常危险的事情。不过怎么说呢,直接基于tcp好像确实有点力不从心吧,要考虑的东西太多了,与GFW背后的人员规模相比,一定是发现的问题总比修复的问题多吧。 |
|
gRPC 是一种通信机制,同级的有 Restful、GraphQL gRPC over ProtoBuf over HTTP/2 over TLS over TCP 其实没必要多一层 ProtoBuf,就像没必要多一层 JSON |
Well, good sum up. Yea I forgot obfs4 and lampshade, they are seasoned protocols as well.
Yep, that's why I said in my comment that making a stream unidentifiable is a world-class difficult problem.
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. |
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.
Randomness is not a weakness. Improper randomization of packet length is. After the discontinuation of SSR, SSRR proposed 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. |
I did have some proposals in my mind, but I am glad to see that smarter people are working on some solutions.
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. |
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..) |
@Kylejustknows |
来说下我的设想:协议不仅要每次安装随机换一个,每天定时换一个,甚至 related: v2ray/discussion#711 |
数据包长度(或其他特性), 每小时一换/每天一换, 这就是特征, 肯定会被封. 因为网上正常的服务器没有这样特性的。 数据包太固定, 是特征; 数据包太随机, 也是明显特征. 上面贴的 NaïveProxy 的流量分析, 可以让我们窥探一下真正的一个TLS握手的数据包"模样", 你可以看出, 协议都是有自己复杂的特征"指纹"的, 仅仅数据包的大小这一个层面, 各个协议、使用不同的客户端,都会产生特有的统计纹路. 这些跟PPPoE重新拨号换IP等没有联系。GFW直接封掉你服务器的IP,跟客户端没关系。 |
最后半句是你脑补的还是有确切证据的? 只要流量不规范,就封服务器 IP,通管局就不怕投诉电话被打爆?😂😂😂😂 其实说到底,被封只有一个原因。那就是使用人数太多,被立了专项攻关。 |
哎,因为网上多数“合法的”服务器,基本都是一个主机单纯提供一个服务(网页服务器、流媒体服务器、游戏服务器等等),它们的数据包,统计起来都是常年很有规律的。
它们真不怕。大概一两年前我自己写的一个只有几十行代码的管理小工具,服务端和客户端TCP连接后传递一些命令和二进制(你就当是个简单的聊天软件吧),测试时有次我把服务端放在香港VPS上,结果运行了几分钟就被断了。当出现墙不认识的可疑流量,它一不高兴就会随机地reset你,作为个人用户我猜哪怕我打电话投诉,“通管局”或者中国电信对我的情况也一无所知,因为这事发生在国际网关并且是全自动的。 |
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. |
老哥,你这个可以复现么。 莫非是阿里 vps。。。按照我的经验,reset 针对单个服务器端口,你换个端口试试呢?
Are you using VPS providers like bwh or linode? Yet changing system is good idea, change protocol is terrible idea. Gasp!
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? |
换一个端口,肯定是我最先做的事情啦,新端口坚持几分钟就又被封了。这事很久了,仔细想想不止一两年了(时间过得真快啊),长城是好几个进化之前的了,不代表现在的情况。 |
It was a VPS provider, but not a famous one.
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.
I have no proof I'm willing to share publicly. These people are already endangered to begin with. |
@Kylejustknows 個人覺得我們是不是應該換一種戰略思維?畢竟對於翻墻方來説面對的是完全不成比例的國家資源項目,對於這種不能正面對抗的對手,除了像你所説的讓各種土製協議遍地開花來分散對手的資源外,真正有效的方法我覺得是盡可能的以小博大讓對方陷入糾結,即讓某種協議的封禁連帶造成不可預估的巨大經濟損失,使墻在明知道存在翻墻行爲的情況下也不敢輕舉妄動,因此我認爲徹底混進標準https流量裏的協議才是最有效的。 |
早年有人提出过路由层面的翻墙伪装项目。 就是从中国这边看起来用户在访问微软的服务器,IP什么的都是微软的,但是流量包到达美国的光纤入口路由后,路由能识别出数据包内隐藏的内容,然后把用户数据转发到真正想要访问的服务器。这项目需要网络底层和国家层面的支持。只是后来不知道怎样了。 |
早年推不動是正常,今年就不一樣了,如果有議員願意推動類似議案並且不是和微軟之類美國本土企業綁定而是和中共在美宣傳機構的流量綁定、比如抖音,估計獲得通過的可能很大,畢竟改動路由的支出很低,而且不會觸及政治敏感的言論自由同時可以抑制中共在美的宣傳活動。 |
任何协议都会有特征,要明白什么样的流量才能过境,当然是Https了。直接基于tcp的协议设计得再好也是鸡累, |
1是如果你对着海外一个ip访问了几个GB的纯https,这本身就高疑。2是对https进行流量特征分析,墙已经能准确判断出你访问的真实网站。 |
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 |
如今 |
即持续不断的噪音,并将数据嵌入其中、消除流量时序特征,什么都分析不出来。 |
2020-06-20 更新:
[New Protocol] VLESS ALPHA
2020-06-05 更新:
更详细的方案:非可信通路 与 可信通路(VMore and VLess),含 VLess 具体设计方案 #2547
什么是 “基于 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#7112020-06-02 更新:
对于 VMess 2 的设计,不反对,可以同时进行
有人觉得基于纯 TCP/UDP 的协议也安全可靠,那想用就用
希望看到更多基于 TLS 的协议(或者说不同的流量混淆方案
其它地方已经有类似的方案,我相信基于 TLS 设计协议正在成为主流方向
V2Ray ≠ VMess,V2Ray 的初衷应该是与时俱进,而不是死守一种方案
毕竟,我们为了 fq 而设计的这些土制协议,有非基于纯 TCP 不可的原因吗?
The text was updated successfully, but these errors were encountered: