chore: remove vmess from core.

[Jolymmiles]

the goal is to remove the obsolete protocol

[ImMohammad20000]

Its better to remove vmess after vless encryption added

[M03ED]

well done, destroy backward compatibility and ruin all clients use xray

[ImMohammad20000]

Also so many people use tcp http configs and vmess for encryption removing vmess not a good idea

[zZedix]

you don't like it you don't use it
Iran's GFW is focusing on TLS encrypted proxies
currently using VMESS is our main solution in this situation
since vless is not encrypted without TLS its a vey bad idea
so leave the vmess alone and don't use it if you don't like it

[vffuunnyy]

well done, destroy backward compatibility and ruin all clients use xray

But keeping deprecated features forever just slows everything down. Protocols evolve for a reason — security, efficiency, and maintainability. It’s not about "ruining" anything — it’s about moving forward.

No one is stopping you from continuing to use older versions of the core if backward compatibility is that critical for your setup. But please don’t expect the latest versions to stay bloated with outdated protocols just to support legacy usage.

Think about the bigger picture — long-term maintainability matters.

[Kiya6955]

Better Option: remove yourself from the world!

[amirsaam]

Unless an encryption method that does not require TLS is added to VLESS, this only helps GFW to do more censoring and not helping the ones who fight against GFW because TLS is easily gets blocked whenever they want.

Add an encryption method, this PR should be marked as Work in Progress :)

P.S: Russia's Gov is not censoring as much as China and Iran, the problem is you think because TLS works in Russia, everywhere else also does work fine, sorry but that's not the case.

[iamtheted]

It's a BIG NO, instead of removing vmess, focus on adding a practical feature.

[M03ED]

But keeping deprecated features forever just slows everything down. Protocols evolve for a reason — security, efficiency, and maintainability. It’s not about "ruining" anything — it’s about moving forward.

No one is stopping you from continuing to use older versions of the core if backward compatibility is that critical for your setup. But please don’t expect the latest versions to stay bloated with outdated protocols just to support legacy usage.

Think about the bigger picture — long-term maintainability matters.

there is a third option if this pr merged, abandon xray and use a alternatives, no more pr on this repo because maintainers like rprx don't commit new changes them selves, people have to use alternatives if they need to run vmess, clients have 2 way, use multiple core (same as v2rayn) or replace xray
at the end this will lead to less pr for xray

[Fangliding]

nope

[RPRX]

Xray-core 不会移除已有的功能/协议，除非是内部迭代（旧 XTLS->新 XTLS，H2/QUIC->XHTTP）或彻底没人用了（旧 MTProto）

VMess 非 Xray 原创且支持广泛，不属于 Xray 移除了就能带动其它软件一起移除的协议，也并非彻底没人用了，所以不会被移除

[Johnny256Dawson]

这大概就是格局了吧

[gfw-killer]

This is a sign!
@RPRX Please prioritize VLESS Encryption
It's more urgent than Vision Seed and Switch (as XHTTP has both features)
but VMess encryption is not as safe as it should be
Governments have fun with non-encrypted VLESS and even VLESS+TLS when it's going through their or data-broker CDNs
even when it's VMESS+TLS but airport subscription is also tunneled via the same CDN (Gov. have the static passsword), or when user shares/gets it's vmess config share link via a government controlled line like SMS or domestic messenger/social media

[RPRX]

@gfw-killer Ok, I wiil see what I can do for solving these problems.

大概就是客户端持有 X25519 与 MLKEM768 公钥，生成密码密文并加密数据发给服务端，服务端持有 X25519 与 MLKEM768 私钥以解密出密码并解密密文数据，密文部分数据传输格式就是 TLS data record，以便在未来的版本中结合 Vision Seed 流量混淆机制

简单设计的话该加密自身为 0-RTT、抗量子，客户端配置泄露不会导致被解密，服务端配置泄露会导致被解密，但还好，因为该加密的微观特征明显，目标并非直接过墙（2025 了都），而是保护数据免受 CDN 的窥探，也就是说外面还有一层 TLS 的保护

如果有人将这一高强度土制加密放明文 HTTP 里面但导致被 GFW 封锁了，则可以证实 GFW 针对明文 HTTP 的审查，这就是阳谋

得益于 VLESS 预留了 "encryption":"none"，如果客户端不支持该加密则不会发出数据而是会报错，下个月的版本就发这个吧

[RPRX]

话说 2025 了基本都有 AES-NI 了吧，加密方式只有 AES-256-GCM 没问题吧

[gfw-killer]

Please add chacha20-poly1305 option too, it's needed for devices with no AES-NI (old or budget devices)
https://gist.github.com/raycoll/62a660602b9ec9fb67b6443f16732080
It's possible to check if device has it or no, then fallback to chacha20-poly1305
https://github.com/klauspost/cpuid

[RPRX]

主要是不想把这个加密设计得过于复杂，服务端可以先 aes-256-gcm 解密，失败的话就试 chacha20-poly1305

[gfw-killer]

If it's gonna have a Header and Payload part like VMess, then Header encryption can always be AES then header determines the payload encryption algorithm.
If not, then decryption in VLESS Inbound can have multiple choices, for example :
"decryption": "chacha20-poly1305,aes-256-gcm" (first try chacha20-poly1305 then try aes-256-gcm)
but if it has no separated Header and Payload parts, then it will be expensive for server to check if the incoming connection is valid or no, as partial decryption of GCM or Poly1305 algorithms is not possible, then vless fallback will be slow and maybe it also become vulnerable to denial of service

[RPRX]

If it's gonna have a Header and Payload part like VMess, then Header encryption can always be AES then header determines the payload encryption algorithm.

其实我不想设计这种机制，因为尝试两次解密的开销对于后面庞大的 body 来说不值一提，基本上没什么额外开销

[RPRX]

@gfw-killer 我更新了 VLESS 加密的设计方案，像 QUIC 一样跨二元组复用 sharedKey，兼顾 0-RTT 与前向安全，测试代码已跑通

本周末将正式推出 VLESS 加密，主要特性如下：

• 抗量子的认证与加密，0-RTT
• 前向安全，重放防护
• 更优的性能，且可选 XTLS

全面基于 ML-KEM-768、HKDF(SHA256)、AES-256-GCM/ChaCha20-Poly1305

[RPRX]

https://t.me/projectXray/4394072

风扇滑翔翼, [2025/8/6 20:06]
xtls已经有这些了就不用兼容xtls了 吧

Project X Channel, [2025/8/6 20:07]
XTLS 是流控不是加密，处理 TiT 和裸奔用的

意思就是 CDN TLS 流量特征由 XTLS 处理，且可以裸奔避免二次加密

风扇滑翔翼, [2025/8/6 20:08]
那个mlkem是啥说法 仿reality那样?

Vesilia, [2025/8/6 20:09]
我想了一下 VLESS 加密不用 ML-DSA-65 做认证了，用 ML-KEM-768，服务端生成解封装 key 和对应的封装 key，后者只有 1088 字节由客户端配置存着，首次连接时把认证密钥密文和自己的临时封装 key 发给服务端，服务端用共享密钥加密或 hash 认证密钥发给客户端即可认证服务端的身份，要不要引入 x25519 我还在思考

Vesilia, [2025/8/6 20:09]
https://github.com/XTLS/Xray-core/pull/4992#issuecomment-3156162191

Project X Channel, [2025/8/6 20:09]
差不多，但 REALITY 的认证用不了这种方式，因为 Client Hello 塞不下

VLESS 用这种方式主要是 all in ML-KEM-768，以及防止二维码塞不下

风扇滑翔翼, [2025/8/6 20:12]
所以复用是之前说的 HKDF(ticket, salt)吗

Project X Channel, [2025/8/6 20:13]
决定不引入 X25519 了，这玩意儿基本不出十年就废了

Project X Channel, [2025/8/6 20:13]
对，服务端只存十分钟，十分钟后密钥扔掉即前向安全，且重放无效

风扇滑翔翼, [2025/8/6 20:14]
这些握手数据放哪 那些空置了几年的proto吗

Project X Channel, [2025/8/6 20:15]
加密是套在现有协议外层的，VLESS 和 flow 在内层

过 CDN 的话，因为只是不想 CDN 看到 SNI，可以 XTLS 避免二次加密

风扇滑翔翼, [2025/8/6 20:17]
有续火吗 比如协商一个新的ticket或者给这个ticket续命 还是说10分支重新握
以及如果服务端完全丢了ticket(eg 重启)能不能回退回原握手 还是失败重试

Project X Channel, [2025/8/6 20:19]
临到期前客户端发起重新协商，客户端如果几次连接失败也会重新协商

风扇滑翔翼, [2025/8/6 20:21]
服务端不认识这个ticket回个reject这样快点吧

Project X Channel, [2025/8/6 20:22]
可以实现明确拒绝，帮助客户端确定是网络问题还是，不过如果攻击者拦截这个拒绝信息，不过好像攻击者在一开始就拦截更快

服务端发送非 TLSv1.3 record 形式的数据实现明确拒绝吧

Yuhan6665, [2025/8/6 20:23]
突然开始填坑 orz

Project X Channel, [2025/8/6 20:25]
gfw-killer 一人多次血书

风扇滑翔翼, [2025/8/6 20:29]
最好收到reject了再丢弃ticket 不然纯网络问题没理由丢
还有用sync map存[dialerConf]ticket 的话可以用用utils里有一个TypedSyncMap

Project X Channel, [2025/8/6 20:32]
现在决定是这样的

这个 ticket 就是 32 字节，似乎没必要 TypedSyncMap？

风扇滑翔翼, [2025/8/6 20:34]
不用sync map就随便

Project X Channel, [2025/8/6 20:34]
是 sync.Map

我看到你写的那个 TypedSyncMap 了，我试试用一下

U̶nknowNㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤ, [2025/8/6 20:49]
Currently XTLS is limited to TCP+TLS/Reality, will the new XTLS also support ws/grpc/xhttp for cdn usage?

Project X Channel, [2025/8/6 20:50]
对

[RPRX]

@Fangliding

话说由于 增强 mux 也在计划中，我在想要不再出个 1-RTT 的模式实现不复用 sharedKey 时的前向安全，防止有人蛐蛐十分钟

但感觉有点没必要

[RPRX]

因为把“多个被代理连接”用 mux 塞进同一条 VLESS 加密内，相较于复用 sharedKey 加密“多个被代理连接”

那如果这个 sharedKey 泄露了，结果都是能解密出“多个被代理连接”，这踏马本质上是一样的

[RPRX]

而如果不 mux 也不复用 sharedKey 的话，在 TCP TLS 2-RTT 的基础上再加 1-RTT，这很有想法，用户测出延迟高的话更会被吐槽

[Fangliding]

重要的不是泄露sharedKey而是不过滤的话请求可以被重放(
加过滤器会导致那个拒绝服务攻击那为什么中间人不一开始就掐断连接呢 毕竟vless加密说了目的不是隐蔽自己是vless

[RPRX]

@Fangliding 不过你要想一下主要目标是放 CDN 里，CDN 去执行这个重放来攻击自己的用户吗

[RPRX]

不过 GET 难说，POST 的话肯定不会，连浏览器都有提示

[Fangliding]

只是提一嘴 毕竟这个实现也简单 一个map就行了 多少数据查找都是O(1) 甚至比vmess的都简单 因为过期销毁整张map都不需要考虑清除过期条目的问题

[RPRX]

那等有人恶意蛐蛐的话再加

我想了下 1-RTT 的模式也是暂时不加，因为下个版本主打配合 XHTTP 而不是非去开 mux.cool，XHTTP 自带了 XMUX 与 padding

等晚些时候增强 mux 以及出 Vision Seed 时再考虑加 1-RTT 模式

[RPRX]

或者不复用 sharedKey，通过第一条连接不停地交换密钥，主打一个防止被蛐蛐

[RPRX]

比如说服务端基于不同的 decapsulationKey 不停地给客户端发 encapsulationKey，客户端每次用一个，但这样的话消耗有点大

[RPRX]

还有讨论过很多次的“预连接”：通过提前连接消除任何 RTT

[RPRX]

但是我感觉也就适合 XTLS 裸奔，不然不如 maxConcurrency=1

[RPRX]

可以用 Vision Seed 给裸奔模式加个这东西，两年前好像在频道说过

[RPRX]

NIST 建议 2030 年后逐步淘汰易受量子计算机攻击的加密算法，2035 年后全面禁用，这就是“十年”的来源

并不是说十年后的量子计算机一定能破解 X25519，而是十年间它会逐步沦为有已知缺陷的过时算法，所以它确实会被人们“干掉”

不过也不好说，叠上现在 AI 的发展速度，未来可期

找个空姐当老婆, [2025/8/6 21:47]
vless加密相对于vmess有哪些优势和不足

Project X Channel, [2025/8/6 21:53]
对比下写的那三条中 VMess 没有哪些不就知道了

VMess 只有 0-RTT 与重放防护，其它的都没

K, [2025/8/7 1:12]
认证用 Curve25519 又何妨，又不用担心 harvest now, decrypt later 的问题

Project X Channel, [2025/8/7 15:51]
那以后不是得重新设计吗

[RPRX]

好消息，1-RTT 模式也会同步推出，因为它更简单，不用服务端存状态，顺手做了

服务端配置为：

"decryption": "1rtt-mlkem768seed-bas64RawURLEncoding" // 只允许 1-RTT 模式

"decryption": "10min-mlkem768seed-bas64RawURLEncoding" // 同时允许 1-RTT 模式与十分钟复用的 0-RTT 模式

客户端配置为：

"encryption": "1rtt-mlkem768client-bas64RawURLEncoding"

"encryption": "8min-mlkem768client-bas64RawURLEncoding" // 复用八分钟后协商新的 sharedKey，需小于服务端的值

[RPRX]

怎么每过一段时间就有一个自以为是的傻逼小号出来刷存在感浪费我时间？一副寻衅滋事的态度，blocked @ettings

X25519 公钥需要混淆这类问题，早就讨论过了 net4people/bbs#287 (comment)

以及 VLESS 加密的目的并非在于隐藏自己是 VLESS 协议，就是要特征拉满，也早就说过了 #3402 (comment)

还有，2025 年了还有人觉得非要长成全随机数的样子才是“没有特征”，这种想法我在刚开始写代理时就否定过了，五年了都

[gfw-killer]

Could you please share details of your final design and a sample server and client config, other developers and cryptographers may give good ideas before it's release

Personally I think it's good to add non-TLS to your threat model, can simply encrypt the client's initial request using a static passphrase like server's x25519 public key's string and parse it by it's length in server side, not to make the non-TLS VLESS undetectable, just not to make the protocol not shout that it's VLESS!
and as a developer suggested in tg, a anti-replay filter feature (i'm not sure if it's even important to defend against replay attack! this attack seems harmless! or maybe i found no good source to read about it)

And you can add a Ed25519 public key from server to the client config to validate the server handshake to protect against an Active MITM attacker (if client's init message be encrypted by a static key, then active MITM can only attack if client config is leaked, but signing server handshake will make it not possible for attacker to MITM even when client config is leaked, as MITM don't have Ed25519's private key)

note: My understanding of Anti-censorship protocols and Cryptography is not perfect, so if i am wrong then correct me, i like to learn more. thank you.

[RPRX]

@gfw-killer 代码可能于后天放出，我没有时间提前分享更多信息

[RPRX]

@gfw-killer 不过关于明文 HTTP 作为底层传输，我的看法已经说过 #4952 (comment)

如果有人将这一高强度土制加密放明文 HTTP 里面但导致被 GFW 封锁了，则可以证实 GFW 针对明文 HTTP 的审查，这就是阳谋

设想一下，如果伊朗 GFW 封锁（明文 HTTP 里面的）VLESS 加密，却不封锁那些全随机数协议（全是对称 PSK），那只能证明：

1. 伊朗 GFW 确实存在针对明文 HTTP 的记录与审查（像是在说废话）
2. 伊朗 GFW 只希望你们使用那些它拿到客户端配置就能解密以前、以后的所有流量的低级土制加密协议

我觉得这将会是个很有趣的测试

[RPRX]

@gfw-killer 关于防重放，我觉得 @Fangliding 说的 #4952 (comment) 挺有道理，map 存一下就行，反正十分钟后就销毁，没有什么成本，应该会实现；关于认证，参考 #4992 (comment) ，不过我又改了一下，防止被蛐蛐 CK 模型下的安全性什么的

[gfw-killer]

Imagine that if Iranian GFW blocks VLESS encryption (inside plaintext HTTP) without blocking those fully random number protocols (all symmetric PSK), that would only prove:

1. Record-and-censorship for cleartext HTTP does exist in Iran GFW (Like talking nonsense）
2. Iran GFW just wants you to use those low-level home-made encryption protocols that can decrypt all previous and subsequent traffic by getting to the client configuration

I think it's going to be a pretty interesting test

It's not just Fully random traffic in HTTP, there is mKCP with different shapes, RAW TCP and maybe RAW Datagram the in future
They easily mimic unknown/private or known fully encrypted protocols (some of them are whitelisted by their Port, easy to exploit by VMESS+RAW/mKCP and Hy2 Salamander)
And there is a lot of different scenarios, for example some Iranian ISPs adds delay to even domestic TLS traffic (maybe GFW hw limit), but as they just whitelist HTTP or Unknown traffic to domestic IPs, proxy providers who has a domestic VPS use non-encrypted VLESS non-TLS from client to Iran VPS Relay (as old devices/os can't connect to VMESS as it relies on device's time, and those old devices does not have after 2022 updates like https://techcommunity.microsoft.com/blog/dstblog/iran-2023-time-zone-update-now-available/3805707)

[RPRX]

@gfw-killer 我还是更想先进行这个有趣的测试，如果有非 TLS 的 VLESS 加密被封锁而全随机数没有被封锁，届时再加上混淆机制