由于我的 Blog 原始文件托管在 GitHub pages 上,推送到个人仓库后上一篇文章立即被相关人士扩散并引发争议,并被指出内容存在错误。
事后,我与该作者进行了交流,也重新分析了相关协议,所以我在这里分享我的改正的对 VLESS 协议的新的理解。
由于有好事者盯着我的个人仓库看,我已经将其转为 private,且也不会删除上一篇文章,留作参考。
我上一篇文章写:
Xray 对 UUID 使用了 ReadFull,这意味着 VLESS 可能并没有与 Trojan 相同的探测保护,向其发送 1+15
字节后停止,服务器长时间等待将会成为特征。
但这是错误的,由于我简易检查时忽略了 Xray 代码的复杂度,没有发现外部再次嵌套了缓冲区再次进行了处理,这也是他在频道中唯一反驳我的。
关于 VLESS 的设计,我曾以为如此设计必然不会主动宣传,然而我确实在文档中发现了作者对此的解释。
version
“协议版本”不仅能起到“响应认证”的作用,还赋予了 VLESS 无痛升级协议结构的能力,带来无限的可能性。 “协议版本”在测试版本中均为 0,正式版本中为 1,以后若有不兼容的协议结构变更则应升级版本。
VLESS 服务端的设计是 switch version,即同时支持所有 VLESS 版本。若需要升级协议版本(可能到不了这一步),推荐的做法是服务端提前一个月支持,一个月后再改客户端。VMess 请求也有协议版本,但它的认证信息在外面,指令部分则高度耦合且有固定加密,导致里面的协议版本毫无意义,服务端也没有进行判断,响应则没有协议版本。Trojan 的协议结构中没有协议版本。
总结:VLESS 具有无痛升级协议结构的能力、无限的可能性、同时支持所有版本;VMess 请求也有协议版本,但毫无意义;Trojan 的协议结构中没有协议版本。
简单一个 version 字段说明即可看到作者的语文功力。然而,没有提到的是:
- VMess 兼容至少三种版本的旧协议
- Trojan 设计简单、设计此字段没有作用
- VLESS 始终使用 0 作为版本号,从未有过 “正式版本”
而 VLESS 即使在 patch release 中 break 了 vision 子协议,也没有修改过该字段。
当我检查当时的版本时,发现 Release Notes 都已经被删除,而被编辑为一个 Telegram Channel 的中文 post,没有任何对协议修改的描述,剩下的更新内容也只有类似的宣传。
uuid
接下来是 UUID,我本来觉得 16 字节有点长,曾经考虑过缩短它,但后来看到 Trojan 用了 56 个可打印字符(56 字节),就彻底打消了这个念头。服务端每次都要验证 UUID,所以性能也很重要:VLESS 的 Validator 经历了多次重构/升级,相较于 VMess,它十分简洁且耗资源很少,可以同时支持非常多的用户,性能也十分强悍,验证速度极快(sync.Map)。API 动态增删用户则更高效顺滑。 https://github.com/XTLS/Xray-core/issues/158
总结:比 Trojan 更简单,相较于 VMess 更简洁、消耗资源更少,“可以支持非常多的用户,性能也十分强悍,验证速度极快,API 动态增删用户则更高效顺滑”。
没有说的:
Trojan 使用密码 + KDF 而不是 UUID,滥用 UUID 作为密码和 key 与错误的 UDP 设计一样继承自 VMess。从安全性上来讲,使用相同长度的密码,对 Trojan 进行暴力破解需要更多的尝试次数,且如果连接被 TLS 中间人解密,Trojan 也不会泄漏原始密码文本。
后半段是一种田忌赛马的对比法,VLESS 和 VMess 根本不是同类型的协议,而这些鲜艳的优点并不是因为 VLESS 作出了什么改进,而是因为 VMess 为了兼容性保留了大量历史遗留设计,即使这些优点对于的 Trojan 都不存在也要拿来宣传,可以一瞥作者的思维。
protobuf
引入 ProtoBuf 是一个创举,等下会详细讲解。“指令”到“地址”的结构目前与 VMess 完全相同,同样支持 Mux。
似乎只有 VLESS 可选内嵌 ProtoBuf,它是一种数据交换格式,信息被紧密编码成二进制,TLV 结构(Tag Length Value)。
总结第一段:
- 使用 ProtoBuf 来序列化 string 是一个创举 (定义结论)
- 似乎只有 VLESS 可选内嵌 ProtoBuf (暗示)
起因是我看到一篇文章称 SS 有一些缺点,如没有设计错误回报机制,客户端没办法根据不同的错误采取进一步的动作。 (但我并不认同所有错误都要回报,不然防不了主动探测。下一个测试版中,服务器可以返回一串自定义信息。) 于是想到一个可扩展的结构是很重要的,未来它也可以承载如动态端口指令。不止响应,请求也需要类似的结构。 本来打算自己设计 TLV,接着发觉 ProtoBuf 就是此结构、现成的轮子,完全适合用来做这件事,各语言支持等也不错。
目前“附加信息”只有 Scheduler 和 SchedulerV,它们是 MessName 和 MessSeed 的替代者,当你不需要它们时,“附加信息长度”为 0,也就不会有 ProtoBuf 序列化/反序列化的开销。其实我更愿意称这个过程为“拼接”,因为 pb 实际原理上也只是这么做而已,相关开销极小。拼接后的 bytes 十分紧凑,和 ALPHA 的方案相差无几,有兴趣的可以分别输出并对比。
为了指示对附加信息(Addons,也可以理解成插件,以后可以有很多个插件)的不同支持程度,下个测试版会在“附加信息长度”前新增“附加信息版本”。256 - 1 = 255 字节是够用且合理的(65535 就太多了,还可能有人恶意填充),现有的只用了十分之一,以后也不会同时有那么多附加信息,且大多数情况下是完全没有附加信息的。真不够用的话,可以升级 VLESS 版本。
为了减少逻辑判断等开销,暂定 Addons 不使用多级结构。一个月前出现过“可变协议格式”的想法,pb 是可以做到打乱顺序,但没必要,因为现代加密的设计不会让旁观者看出两次传输的头部相同。
下面介绍 Schedulers 和 Encryption 的构想,它们都是可选的,一个应对流量时序特征问题,一个应对密码学上的问题。
这是展示其设计水平的关键段落,我将其分为两个部分:
- 认为 “一个可扩展的结构” 对于错误回报机制是很重要的。
实际上还是从 VMess 继承的思维,认为协议与 “传输层” 和 “XTLS” 等大量子协议组合分离、随意更改是没有问题的。随之而来的,既然要应对其他协议的更新,就需要允许可变甚至存在未知数据的协议格式。
这种思维的语言腐败遗毒深远,导致大多数不明所以的人认为 V2Ray 发明的私有 “传输层” 不是使用这些协议名字的私有未定义格式,而是是一种通用的协议,且与非 V2Ray 系协议的组合是没有问题的,而不是一种未定义行为。
- 认为对于序列化非定长的数据结构,更应该使用 ProtoBuf,原因包括各语言支持都不错
这是其设计的最核心问题,我想用一些例子解释。
对于其实际传输的子协议名称 flow,最少的数据格式可以为:
Flow |
---|
uint8 |
这完全足够,在可预见的未来内, VLESS 不会有超过 256 个子协议。
如果考虑到要像 TLS extension 一样支持扩展,可以设计为:
Length | Flow |
---|---|
uint8 | uint8 |
仍然完全足够,使用 uint8 作为长度,是因为作者称 255 字节是够用且合理的。
但 VLESS 使用的实际格式为:
ProtoBuf Length | ProtoBuf Header | Flow Length | Flow | Seed Length | Seed |
---|---|---|---|---|---|
uint8 | byte | uvariant | string | uvariant | string |
不仅将子协议常量作为字符串传输,还在总长限定为 255 以内的数据内对其字段使用了 uvariant,即一种允许长度大于 255 的格式。
从 ”当你不需要它们时,也就不会有 ProtoBuf 序列化/反序列化的开销” 中也可以看出作者实际上并不熟悉数据格式,才对于一到二个字节可以传输的结构,使用了与 JSON 同类的的二进制应用层协议 ProtoBuf v2 message 来代替编写二进制协议。
不仅如此,VLESS 的服务器回应直接使用了请求中的 ProtoBuf 格式作为回应内容;在实际使用中,这些字段从未赋值,也没有实现上文提到的 ”错误指示“ 功能。
UDP 问题
VLESS 继承了与 VMess 一样,但又不存在于其他所有代理协议的设计问题。鉴于很多人对此不了解,我想对相关介绍作出一些简单解释:
UDP 是基于数据包而不是流的协议,因此,在应用传输中,每一个数据包都带有目标地址;但 V2Ray 由于早期开发者设计水平问题,在架构中将 UDP 数据包 DNAT 后为作为连接与 TCP 一同作为流来中继。
而作者的修复方式是发明一个新的子协议,在其中添加 UDP 地址以达到修复的目的,这也显现出了作者在协议设计上的不专业。
而关于作者对这个新的子协议的描述作为结尾:
#237 已阐明 V 系协议的 UoT 结构无法实现 FullCone,然而 Xray-core v1.3.0+ 却神奇地做到了本被认为是不可能的事情:
至此,Xray-core 实现了全协议、全出入站、全传输方式完美支持 FullCone 🎉
最后,仓库右上角点个 Star,谢谢!
尾声
与 VMess 的高度耦合不同,VLESS 的服务端、客户端不久后可以提前约定好加密方式,仅在外面套一层加密。这有点类似于使用 TLS,不影响承载的任何数据,也可以理解成底层就是从 TLS 换成预设约定加密。相对于高度耦合,这种方式更合理且灵活:一种加密方式出了安全性问题,直接扔掉并换用其它的就行了,十分方便。VLESS 服务端还会允许不同的加密方式共存。
对比 VMess,VLESS 相当于把 security 换成 encryption,把 disableInsecureEncryption 换成 decryption,就解决了所有问题。目前 encryption 和 decryption 只接受 "none" 且不能留空(即使以后有连接安全性检查),详见 VLESS 配置文档
VLESS 作为一个在基本只会在 TLS 内传输的协议,宣传是对 VMess 这样的全加密协议的改进,处处拿 VMess 论证先进性;而实际上继承了 VMess 的大量缺点,就连目标地址格式也照搬 VMess,而不是使用被 SOCKS、Shadowsocks、Trojan 等协议广泛使用的 socksaddr。
关于这个协议的总结:整体设计起源于 Trojan、包含了大量 VMess 的缺点、实现了 Xray 需要在不修改协议的情况下修改协议(附加子协议) 的需求。