Shadowsocks/Vmess到底怎么选?安全性如何?

Shadowsocks/Vmess到底怎么选?安全性如何?

image

起因

入冬后,准确来说是在秋季,就感觉原来的小机场偶尔会出现大批节点无法连接的情况,今年1月底到期,在考虑几年了是否该更换跑路,不过好在相对便宜,故障一会就好,还能接受。

然而在将要到期的前几天的时间点上,它刚好又出现了中断,且持续了近1个小时,这对打工人来说不太能接受了,于是便舍弃了原来的小机场,投奔朋友推荐的更大一家。

image

但这里有两个问题,一个是用什么代理软件,第二个是用什么代理协议,这两个问题是逐步浮现的。

代理软件

由于个人职业与所处行业原因,接触墙外比较早(小时候到外服体验新版本游戏),也在之前就尝试自己搭过VPS,详见Try-for-V2Ray,后来由于Vultr质量真的不堪入目、WS+TLS需要的域名证书也是一笔费用且麻烦(才不是懒),项目算是咕掉了,但其中学习到的知识与相关技术还没全忘,用到的各种代理软件也还是多的。

Clash

你要我从中选择,移动端PC端我都会毫不犹豫的选择Clash,谁能拒绝可爱猫猫?但是,可爱猫猫在2023年11月寄掉了!与之相关的Core、Pro、X等都闻风而逝(只猫,影逝二度),仅留下永远停止更新的本地客户端。

image

虽然现在才1月底,最后一次release在3个月前,但时间越长,对于一个曾开源项目来说就越危险,必须要有可行的安全性选择(我也曾考虑过不这么麻烦,直接用之前的不就好了,然后我在互联网上“看着不错还蛮正经”的网站上获取的ClashX远程服务端口就被修改过了)。

V2rayU

撰写此文时,我新入职的公司使用的是MAC M2办公,在第一家公司就使用MAC的我并无什么不适应,但是ClashX在我入职前就化作灰烬,我在换机场前就已经在使用V2rayU,这是个专走Vmess协议的Proxy,虽然repo已有两年未更新了,但是release其实作者一直在偷偷更新。

image

然而,当我切换到新的机场订阅时,却发现机场节点的一句提醒:

因V2ray重大漏洞问题,暂时下架全部V2节点。请使用ssr/ss连接方式进行使用

image

代理协议

所以这是怎么回事?

我依稀记得我玩个人VPS那些年还在传VMESS协议更加安全,V2ray可以用更多的传输配置才对啊?这个重大漏洞是什么,CVE编号多少?(啊,这就是职业病)

V2ray重大漏洞

V2ray协议爆发了重大安全漏洞

漏洞的描述简单来说就是:

v2ray的TLS流量可被简单特征码匹配精准识别,vmess协议设计和实现缺陷可导致服务器遭到主动探测特征识别

这两方面的问题不论哪个都会使得用V2ray作为Proxy、VMESS作协议进行传输的墙外访问方式被轻松识别到,虽然不同于传统安全漏洞,但确实是严重问题。

服务器端的 V2ray 更新到 v4.23.4 以及之后的版本可以解决这一问题, 请大家尽快更新.

截止本文撰写,V2ray-Core的最新release已经到5.12.1,可是这个问题应该早已经被修复了,为什么现在订阅还有这样的提示,不让使用VMESS协议?

image

如何选择

绕一大圈,让我们回到文章的主标题:

Shadowsocks/Vmess到底怎么选?安全性如何?

先说结论:它们最新版本的实现都是安全的,也都是不安全的

image

为什么这么说?

对于这两种协议甚至更多种的传输协议,想要去了解它的具体实现及传输形式并不难,以Shadowsocks为例,在Shadowsocks协议解析一文中有清晰明了的叙述,Vmess你也应该都能找到类似的内容。

Shadowsocks/Vmess都会采用一定的加密算法,将传输内容进行加密,在浅谈一下Shadowsocks和VMess的安全性一文的评论中,enfein有提到“shadowsocks 协议现阶段还是安全的,但 VMess 在一些领域做得更好,例如使用依赖于时间的密钥生成办法”,这也佐证了我最初认为Vmess协议的安全性设计比Shadowsocks好的看法,那就能说明Vmess安全性更好吗?

image

主要漏洞

我们回忆一下前文提到的“V2ray重大漏洞”,虽然没有被直接破解出传输内容明文,但能精确地探测标识proxy服务器,与在黑暗森林中点火且大喊无异。

那么Shadowsocks有这样的问题吗?

浅谈一下Shadowsocks和VMess的安全性的原文中,作者例举了两个Shadowsocks的相关漏洞:

Shadowsocks AEAD 加密方式设计存在严重漏洞,无法保证通信内容的可靠性

shadowsocks redirect attack exploit

前者也会使proxy服务器因为流量特征被标识而封禁,后者则更致命地可导致传输内容密文被解析。

image

最佳实践

既然大家都是卧龙凤雏,有什么不那么烂的方式吗?

首先要明确的是,最新版本的协议都已经将已知漏洞修复,可以认为两者安全性相近,也都有可能被流量分析与主动探测(即使你采取了防范与伪装)。

针对Shadowsocks,防御GFW主动探测的实用指南一文中指出了Shadowsocks理应达到的最佳实践;相应的,Vmess支持和TLS组合,也可以实现动态端口等,这些在我搭建VPS的时候就已经是个人可以不算复杂的实现了。并且在【还Shadowsocks一个清白】Shadowsocks是如何被检测和封锁的,兼谈ss配置策略一文中,也有提到可以采用国内转国外双重代理的方式,规划ip白名单,规避一些探测(但文章内容主观性较强,观点接纳需分别):

image

此外,在搭建与使用的过程中,不能过分信任某些教程,并不是说它们的方法有问题,而是很多一键部署的脚本为了运行的稳定性与一致性,是写死了引用版本的,那么就很有可能还在利用存在漏洞的协议版本;同时也需要注意客户端的选择,个人现在使用的是Clash Verge Rev(回来吧我的牢猫!),Clash Verge的原repo也因为2023年11月的风波停止更新,Rev是抛弃了原Clash Core(repo removed)采用mihomo重新构建并仍在更新的版本。

image

那为什么不使用V2ray相关的客户端?

一方面是新的机场不支持Vmess(前情提要),一方面是V2ray Core做出的客户端确实没有猫猫可爱(猫猫也支持Vmess等多种协议),再一方面是有些V2ray的客户端的最新release用的Core版本仍处于风险版本(V2rayU:所以爱是会消失的对吗?)

image

机场顾虑

最后一个问题,既然Shadowsocks和Vmess都可以,为什么有些机场不提供Vmess节点了?

这个问题在关于科学上网的流行说法一文中可见一斑:

  • 大部分机场都是中转线路,使用 V2RAY 显得太重,消耗服务器资源大
  • V2RAY在防标识的场景下相比已经搭好的Shadowsocks没有明显优势

所以对于机场线路,公网隧道、专线,没有一定要再采用哪种协议的需求,更多地在考虑带宽等费用与访问流畅度。此外,机场躲避封锁的方式,在文章中也有谈及,同时文章中也有谈到订阅转换的技术,在一些机场也有提供(在逐渐收敛)。

个人小注

对于浏览访问来说,机场提供的服务已经完全够用,除了不能登录服务器进行配置这部分不便,这也是我为什么暂时放弃了自己搭建VPS的想法;

但对于未来的渗透测试来说,虽然简单的OOB可以Dnslog/Ceye,但如果要弹shell,或者境外测试,就还是需要国内云与国外云的服务,这些机场就完全无法支持了。

image

参考引用

Try-for-V2Ray

V2ray协议爆发了重大安全漏洞

Shadowsocks协议解析

浅谈一下Shadowsocks和VMess的安全性

Shadowsocks AEAD 加密方式设计存在严重漏洞,无法保证通信内容的可靠性

shadowsocks redirect attack exploit

防御GFW主动探测的实用指南

【还Shadowsocks一个清白】Shadowsocks是如何被检测和封锁的,兼谈ss配置策略

关于科学上网的流行说法

关于科学上网的流行说法

关于科学上网的流行说法

本文转自Clouder 并作补充

前言

本文意在分析一些经常被提及、引起争论的问题。

为什么不用 V2RAY/Trojan

由于直连打击力度较大,个人自建需要使用更不易被封锁的协议。很多人宣传 V2RAY Trojan 等,事实上对直连也许是有一定帮助的。

但是大部分机场都是中转线路,使用 V2RAY 显得太重,消耗服务器资源大,而实质上并没有什么帮助,因此更青睐老牌的、生态更好的 Shadowsocks 及 ShadowsocksR。

Trojan 也是类似的。

因此发表一些“不用 V2RAY 不怕被封吗”之类的言论,并不明智。

以下是部分大佬对此的看法。(如有冒犯,请联系删除)

image

image

image

image

(本句在当时语境下类似于玩笑话,其本人无任何贬低 Trojan 的意思。)

不可否认,新的协议的出现是必然且有意义的,但其出现一般都是为了解决现有问题。

例如 V2RAY 试图解决的是严重封锁,而 Trojan 试图解决的是 V2RAY 过重的问题。

而机场线路,公网隧道、专线,大概没有此类需求。

此外,Shadowsocks 与 ShadowsocksR 的生态相对成熟。

关于 Shadowsocks 与 ShadowsocksR 有如下说法:

  1. Shadowsocks 每个用户需要占用一个端口,部署可能不便。而 ShadowsocksR 支持端口复用模式。
  2. ShadowsocksR 停止维护,且加密程度相对 Shadowsocks 更高,意味着效率、性能相对较劣,但有传 ShadowsocksR 能缓解 QOS 问题。

目前看来,Shadowsocks 协议支持最为广泛。

以上内容为笔者个人见解,如有谬误,敬请斧正。

IPLC 天下第一吗?

首先,看看毒药博客中的介绍。

  • IPLC: “International Private Leased Circuit”的缩写,即“国际专线”。不过大部分机场通常看到的 iplc,都只是阿里的经典网络,跨数据中心内网互通,阿里内网,并不是严格意义的 iplc 专线;当然也有其他渠道的,或真 iplc,不过比较少。阿里云的内网互通底层原理是通过采购多个点对点的 iplc 专线,来连接各个数据中心,从而把各个数据中心纳入到自己的一套内网里面来。这样做有两个好处,其一是 iplc 链路上的带宽独享,完全不受公网波动影响,其二是过境的时候不需要经过 GFW,确保了数据安全且不受外界各种因素干扰。但是需要注意一下阿里云的 iplc 也是有带宽上限的,如果过多的人同时挤到同一条专线上,峰值带宽超过专线的上限的话也同样会造成网络不稳定。其他渠道购买到的 iplc 价格很高,阿里云内网这种性价比超高这种好东西且用且珍惜。
  • IEPL 国际以太网专线(International Ethernet Private Line,简称 IEPL),构建于 MSTP 设备平台上,基于 SDH 传输技术,采用 GFP 封装,传输协议透明,物理层隔离,带宽保证,提供一层点对点数据专线服务。IEPL 是以太网接口的增强型的 IPLC 产品,是一个端到端的专享管理频宽服务,拥有高度灵活性及最高物理层网络安全功能,让客户轻松管理广域网和高带宽需求的应用。通俗的总结一下,IEPL 使用某种技术,实现了两点之间的高稳定性的数据传输。这与 IPLC,MPLS 是差不多的效果,只是实现的技术手段有区别而已。其实对机场来说,是 IPLC 或者 IEPL 或是 MPLS-VPN,都没有太大区别。认定是保障带宽的不过墙专线就行了,至于是用哪种技术方案实现的,根本不需要纠结。
  • BGP:BGP 的实际意思通常是一个 IP 在多个运营商的网络中均为直连,不经过第三运营商,利用 iptables 或相关软件通过将去海外 VPS 的流量加一层国内转发。不过不同机场的定义也不一样。正常来说比如 rixcloud,指的是他们入口是阿里云、部分落地节点是自己起了 BGP(去 Peer 了 GitHub、微软、Cloudflare 等等)。不过多数机场把 BGP 定义为阿里云公网中转等。
  • 中转:将数据从一个服务器重定向到另外一个服务器。机场中比较常见的是阿里云公网中转,其实也有很多其他中转,也有自己去买其他的 BGP 来中转的。
  • 「原生 IP」:所谓原生 IP 通常意思为当地运营商原本就拥有的 IP;广播国家一般和注册国家相同(一般的 IP 库不会误判地区),一般不用于公有云计算服务或 IP 声誉好,一般能够用来解锁 Netflix、HBO、Hulu 以及其它有限制的流媒体服务
  • 流媒体解锁:很多流媒体服务平台如 Netflix 会出于版权原因而限制一些特定 IP 的访问。一般来说网络运营商(如 HKT)自己持有的 IP,比如商宽、家宽,极少被屏蔽,因为这些 IP 大多是流媒体服务商的目标客户在使用。家宽 IP 被屏蔽的几率是最低的,很多 ISP 的家宽都是动态 IP 的,很难精准封杀。固定 IP 的商宽其次。这些流媒体服务商也怕误杀导致投诉,比如 GCP 的 IP 段被投诉之后又可以看 Netflix 了。IDC 商家所持有的 IP 一般会被屏蔽,越大越有名的 IDC 持有的 IP 被屏蔽的几率越高。很多 IDC 会租用运营商的 IP 从而绕过此类封杀,但是这种方式并不是万无一失的,翻车案例比较多我就不再一一例举了。所以除非是商宽、家宽,其他所谓的“原生 IP 解锁流媒体”都是有几率翻车的。
  • CN2:是电信的精品骨干网。首先 CN2 是一张运营商骨干网,就像电信 163、中国移动这一类是同样性质的东西,但相对电信 163 来说会有更好的稳定性。不是什么专线(和 iplc 那类东西区分清楚)。既然是公网,那它本质上就是个很多人共享使用的东西。共享的东西都存在一定程度的不稳定性。区别在于它的超售比较低,相对电信 163 来说会有更好的质量。CN2 的跨国数据通讯也需要经过 GFW 审查,不存在不过 GFW 的公网。

在谈及 IPLC 时,一般泛指专线。专线相对于公网中转有如下优点:

  1. 不经过 GFW,也就是所谓的不过墙。
  2. 链路宽带独享,不受公网波动影响。

一个中转节点应该是这样的:

image

IPLC 速度快

一般来说,用户更关心的速度是“网速”,也就是宽带大小。

而使用专线并不能改变宽带的容量,因此盲目地认为 IPLC 网速快是毫无根据的。

IPLC 延迟低

专线传输,理论上延迟的确更低。 排除掉机场过度超售、宽带跑满丢包、软件出锅等问题,专线在此方面的确有优势。 虽然一般用户无需过多在意延迟。

IPLC 稳定

专线传输的稳定,主要体现在链路宽带独享,不容易受公网波动影响。 但上游依然会出问题,例如机房事故等等。 而高质量的公网可靠性并不差。

IPLC 安全

不经过 GFW 的处理,在某种意义上安全了。 但专线传输数据仍受到监管,如 ssrcloud 的中日专线有人访问邪教网站遭到警告。

注重隐私请使用 no-log VPN、多层跳板等方式,而不要轻信提供科学上网服务的机场还能保护你的安全。 一般人无需对此过于敏感。

IPLC 贵

专线宽带的价格的确高昂。

下图为花卷科技的 IPLC 专线宽带价格。

image

即使有钻石分销的六折,每 Mbps 也高达 210RMB,每 100 Mbps 价格要达到两三万元。

然而,其实还有更高贵的。如下图,北京动态 BGP 全穿透多线宽带。

image

上图为微网聚力官网的价格表,可以看到最高贵的宽带每 100 Mbps 高达五万元每月。

事实上,单比较价格意义不大,因为可以这样部署:

image

总结

以上内容亦非绝对,笔者目的不在于否定专线等等,而在于提醒各位读者更理性、全面地看待线路,而不要迷信专线等。

100Mbps 的专线给 100 人用,体验可能并不如 1Gbps 的公网隧道给 100 人用。

其实,用户对节点线路无需过多关注,而只需要关注用户体验。用起来好就行,不必在意机场主用了什么神秘的操作。

最后,来点佩奇笑话。

image

image

订阅转换偷订阅

不可否认,在技术上的确是可行的。 然而,让我们看看搭建订阅转换服务的都是什么大佬吧。

bianyuan

边缘订阅转换 API,笔者使用的第一个订阅转换 API。

Sabrina,博客地址为 https://merlinblog.xyz/,N3RO 机场的大佬。

撰写了大量教程,对社区的贡献毋容置疑。对于转换偷订阅的说法,其本人亦有过回应:

image

nameless13

https://api.nameless13.com/,也是相当知名的订阅转换 API 了。

Nameless13,魅影的管理员,撰写了魅影各类教程

gfwsb.114514.best

https://gfwsb.114514.best/,这域名震撼我一万年……

TindyX,subconverter项目的作者。

总结

以上只是订阅转换的一部分。笔者想借此说明的是,搭建这种公益服务者通常为大佬,并不会眼馋你的订阅。 当然并不排除有作恶者存在。 实在担心,建议使用本地版的 subconverter,避免此问题。

Surfboard 快

笔者无端猜测,有小白看了某知名 youtuber 的各大软件速度对比后,认为 Surfboard 更快。

笔者未进行相关测试,但必须指出: 软件并不是网速的主要影响因素,且无明显缺陷的软件,在速度上并不会有太大差异。

网速的主导因素,是线路质量。包括但不限于设备到路由器、家庭宽带到国内入口、国内入口到国内出口、国内出口到国际落地、国际落地到目标服务器的线路质量。

Surfboard 是一个相当优秀的客户端,但请不要以“网速最快”等说法夸赞推荐它,否则可能引发不必要的争端。

关于网速的一些思考

使用 youtube 进行网速测试,会受到硬件性能等因素影响,测速应使用更专业的工具。

据传,旧版本的 Clash For Android 使用的内核有一定的性能问题,已经更换。(来源不详,不必当真)

理想的中高端机场,应当能达到 100Mbps 及以上的速率,选用软件对网速的影响不必多虑。

关于软件速度的一些思考

一般来说,功能越复杂,速度就越慢。在路由器上跑规则复杂的 Clash,可能对网速有较大影响。

使用 PC 客户端,基本不用考虑。移动设备可能有一定影响,但并不大,无需太在意。

此处速度为泛指,结论纯粹笔者臆想,不足为据。

总结

撰写本文的目的,并不是想否定、批评广为流行的某些说法,而是想否定盲目地迷信某些说法的行为。 例如,对机场不提供 V2RAY 提出质疑的小白,吹捧 IPLC 强无敌的小白,认为 Surfboard 天下第一的小白等等……

本文也无意提出什么说法,而仅仅想说明:没有什么是绝对的。请理性评判,不要迷信权威。

That’s All.

引用

  1. ShadowsocksR 端口复用 原文 ↩︎
  2. ShadowsocksR 缓解 QOS 问题 原文 ↩︎
  3. 花卷科技钻石分销 原文 ↩︎
  4. 微网聚力价格表 原文 ↩︎
  5. 几乎所有订阅转换都基于 subconverter↩︎
  6. CFA Release ↩︎

V2ray协议爆发了重大安全漏洞

V2ray协议爆发了重大安全漏洞

本文转自DolorHunter 并作补充

服务器端的 V2ray 更新到 v4.23.4 以及之后的版本可以解决这一问题, 请大家尽快更新.

这可能是 V2ray 自 15 年发布 v1.0.0 以来面临的最大危机.

六一前后, 有大量网友反应自己的裸 V2ray 配置(Vmess+TCP 的默认配置)失效了, 我本来也没太当回事, 毕竟过几天就是 535 了, 断一断网是老传统, 并没有什么好说的. 不过有一点与以往不同, 这次被阻断的用户都是使用默认配置.

V2ray 的默认配置是 Vmess+TCP. 虽然中庸普通, 但它并不是一个容易被阻断的配置. 之前被阻断的 V2ray 配置通常都是些 KCP/mKCP 或是 QUIC 这类的基于 UDP 协议的配置. UDP 通信数据特征明显, 因此容易被 GFW 逮个正着. 而 TCP 是可靠协议, 而且目前大量的网络数据也是基于 TCP 协议, 因此 TCP 协议一直都还算安全.

我的认知里Vmess协议有个安全性排名: Vmess+TCP/WS/HTTP2+TLS > Vmess+TCP/WS/HTTP2 > Vmess+KCP/mKCP/QUIC. 如果用白话来解释就是带TLS的配置是最高一档90分优秀, 中间配置60分及格凑合, 最后一档是不及格. 我一直认为, 只要不用 KCP/mKCP/QUIC 爆炸三兄弟, 还是能舒心上网的. 然而我的预判出了大错误.

发现重大安全漏洞

QV2ray-dev 社区首先发声. 六一当天, QV2ray-dev 警告用户不要使用 Vmess+TCP, 部分 Vmess+WS 及部分 Vmess+ws+TLS(insecure) 的配置组合. 他解释到 GFW 正在进行主动探测, 在 30s 内就可以接近 100% 的探测出你是否使用 Vmess+TCP 的配置, 其他配置亦可以受到波及. 并且此问题并无解决方案, 解决该问题可能需要重新设计 Vmess 协议.

看到了这条消息后, 当下到 V2ray 社区逛了一圈, 发现事态比想象中的严重许多. p4gefau1t 发了一个名为 v2ray的TLS流量可被简单特征码匹配精准识别(附PoC) 的帖子. 过后十几小时又发了个名为 vmess协议设计和实现缺陷可导致服务器遭到主动探测特征识别(附PoC) 的帖子. 这两个帖子在短短几小时内已经获得了数十个回复, 并且多为负责此项目的大牛.

p4gefau1t 首先发现仅凭tls client hello的cipher suite字段,就可以非常准确地将v2ray流量和正常浏览器流量区分开来。

他通过 这篇文章 中提到了使用机器学习训练的模型可对v2ray的tls+ws流量进行识别,准确率高达0.9999. 后来, 经过本地测试,可以复现。并且不限于tls+ws,对tls+vmess等组合也同样有效。其他tls流量如浏览器流量等,全程没有出现误报情况。因此初步怀疑是v2ray使用的utls进行client hello伪造出现的问题。

通过抓包对比真实的chrome与utls的client hello,发现两者基本一致,但与v2ray的存在较大差别,其中包括suite和extension的差别。此后,我们将utls的chrome的cipher suite patch到v2ray中后,此模型无法识别v2ray的tls流量。所以我们可以初步认为,模型很可能是学习了tls client hello的特征,导致流量被识别。

他发现识别tls client hello并不需要使用机器学习的方法,简单的DPI即可实现,因此在gfw部署的成本很低。并且,由于这组cipher suites太过特殊,我们可以仅凭cipher suites进行准确识别。

Cipher Suite 的特征有多特殊呢? 帖子下的网友随手撸一个从 0x90 偏移量开始的 memcmp 都能精准高效识别“特征码”:cca8cca9c02fc02bc030c02cc027c013c023c009c014c00a130113031302 甚至可以利用 iptables 进行明文匹配…… 帖内多个网友用其他配置也多次复现成功, 都得到了相同的特征码.

这个漏洞可以说是十分棘手. 几乎可以说只要 GFW 想, 随时可以全国断网, 并且不分配置(不管有没有 TLS 都是死路一条).

p4gefau1t 在十几个小时后又发了一个帖子. 这次他构造出了更具杀伤性的PoC, 仅需16次探测即可准确判定vmess服务,误报可能性几乎为0,校验的缓解措施均无效。唯一的解决方案是禁用vmess或者重新设计协议。

16 字节 X 字节 余下部分
认证信息 指令部分 数据部分

Vmess 协议前16字节为认证信息,内容为和时间、用户ID相关的散列值。根据协议设计,每个16字节的认证信息auth的有效期只有30秒。而问题出在指令部分。指令部分使用了没有认证能力的aes-cfb方式,因此攻击者可以篡改其中内容,而仍然能被服务器接受。

1 字节 16 字节 16 字节 1 字节 1 字节 4 位 4 位 1 字节 1 字节 2 字节 1 字节 N 字节 P 字节 4 字节
版本号 Ver 数据加密 IV 数据加密 Key 响应认证 V 选项 Opt 余量 P 加密方式 Sec 保留 指令 Cmd 端口 Port 地址类型 T 地址 A 随机值 校验 F

前16字节的认证信息可以被重复使用,并且只要通过认证,执行流即可进行到140行,初始化aes密钥流。接着在144行处,服务端在没有经过任何认证的情况下,读入38字节的密文,并使用aes-cfb进行解密,在没有进行任何校验的情况下,将其中版本号,余量P,加密方式等信息,直接填入结构体中。

这里问题已经很明显了,攻击者只需要得知16字节的认证信息,就可以在30秒内反复修改这38字节的信息进行反复的重放攻击/密文填充攻击。

aes本身可以抵抗已知明文攻击,因此安全性方面基本没有问题。出现问题的是余量P。我猜想设计者应该是为了避免包的长度特征而引入这个字段,但是读入余量的方式出现了问题:在没有校验余量P、加密方式Sec、版本号Ver、指令 Cmd、地址类型T、地址A的情况下,将P直接代入ReadFullFrom中读取P字节(182行)。注意,这里P的范围是2^4=16字节以内。读取P+4字节后,v2ray才会对前面读入的内容进行校验,判断命令部分是否合法。如果不合法,断开连接。

临时性纾困方案

V2ray 社区针对这一漏洞在一周内接连推出了两个小的版本更新, 4.23.3 和 4.23.4.

V2Ray 项目在最近的几天内收到了数个隐匿性能方面的漏洞报告。这些漏洞都在被提出的数个小时内被解决(除 mKCP 修复暂缓)并发布相关更新。您可以升级到最新版本 v4.23.4 来获取最大程度的保护。我们支持和鼓励寻找并提出 V2Ray 各个方面漏洞的人。我们希望 V2Ray 的用户不要指责或者攻击为我们提供安全审计的人士。

可以使用

如果你已经升级到 V2Ray v4.23.4,并且没有开启 TLS 的 AllowInsecure 选项,以下配置组合不会泄露识别信息:

VMess over Websocket with TLS

VMess over TLS

VMess over HTTP/2 (使用 TLS 的 HTTP/2,并非 h2c)

Shadowsocks(AEAD) over Websocket with TLS

谨慎使用

以下配置组合可能会在攻击者位于网络路径上时可能会使攻击者获得的协议数据的一些统计学属性,但是这些信息不足以用于确定服务器上部署了这些协议

VMess over TCP (还在继续改进中) 已修复, 可以正常使用

并不建议

以下配置组合不建议用于穿越被攻击者控制的网络:

任何协议 + SOCKS5

任何协议 + HTTP 代理

任何协议 + HTTP 伪装

任何协议 + mKCP + 任何伪装

-xiaokangwang 于 关于在近期收到的数个漏洞的项目组公告

协议的长期解决方案

重写 Vmess 协议可能是在较长时间内解决这一问题的唯一出路.

Vmess 协议已经诞生了很长一段时间. 那时候互联网上tls并不普及,tls1.3也还没出来。因此协议过时出现问题可以说是必然. 依照此趋势, 我倾向于认为下一代的 Vmess 默认协议可能会是类似 Vmess+TCP/WS/HTTP2+TLS 的设计. HTTP3 短期看来不太可能有具体应用, 毕竟 QUIC 作为 HTTP3的雏形, 翻车翻成什么样大家心里都有数.

这次可能可以说是 V2ray 面世五年来遇到的最大一次危机. 不过, 目前的两个紧急补丁已经缓解了燃眉之急, 并且就 V2ray 社区的效率(两天内连续两个补丁), 我基本上已经消解了我之前的随时可能断网的担忧了.

当前社区内对于新协议的讨论如火如荼, 每天都能看到新的点子冒出来. 过不了多久可能就会见到新的用于替换当前的 Vmess 的协议, 或者是目睹 V2ray 终于要进入 v5.0.0时代. 不论是目睹了其中的任何一件, 都是在见证历史, 见证开源社区的协作, 见证又一次与 GFW 的缠斗.