Forwarded from Sorcerer
Project X Channel
那你有得等了,Xray 配置订阅都出了估计都等不到 mihomo
我xray tun、switch、vision seed、什么时候能等到呢
❤4
Forwarded from Project X Channel
Project X Channel
我xray tun、switch、vision seed、什么时候能等到呢
下个月出完 VLESS 加密就出 Vision Seed,然后是 TUN 和配置订阅
🔥38🎉10❤2
聊到 QUIC,把 REALITY 那一套搬到 QUIC 上不存在技术难度,问题一是 QUIC 允许连接迁移,会暴露这不只是端口转发,问题二是服务端 quic-go 不太符合 Nginx QUIC 等其它软件的特征,感觉时机尚未成熟
👀38👍15⚡4❤1😁1
GitHub
Dokodemo-door: Add simple `tunnel` config (alias and default values) by RPRX · Pull Request #4968 · XTLS/Xray-core
先前讨论:#4966 (comment) ,#4967 (comment)
Xray-core 一直都支持类似于 gost、realm 等软件所谓的“隧道”功能(通过代理协议来端口转发),也就是 dokodemo-door 入站,但是由于当初 v2 起的这个名字不太直观,知道 *ray 还能当“隧道”用的人并不多,导致 dokodemo-door 入站几乎仅用于透明代理
这也提醒各位记得在服...
Xray-core 一直都支持类似于 gost、realm 等软件所谓的“隧道”功能(通过代理协议来端口转发),也就是 dokodemo-door 入站,但是由于当初 v2 起的这个名字不太直观,知道 *ray 还能当“隧道”用的人并不多,导致 dokodemo-door 入站几乎仅用于透明代理
这也提醒各位记得在服...
Tunnel: https://github.com/XTLS/Xray-core/pull/4968
本次久违地放出了一些 REALITY NFT 和几个 Project X NFT
请支持一个 REALITY NFT:https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2
如果你有余力,请支持一个 Project X NFT:https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/1
👍28🔥2🎉2
GitHub
Dokodemo-door: Add simple `tunnel` config (alias and default values) by RPRX · Pull Request #4968 · XTLS/Xray-core
先前讨论:#4966 (comment) ,#4967 (comment)
Xray-core 一直都支持类似于 gost、realm 等软件所谓的“隧道”功能(通过代理协议来端口转发),也就是 dokodemo-door 入站,但是由于当初 v2 起的这个名字不太直观,知道 *ray 还能当“隧道”用的人并不多,导致 dokodemo-door 入站几乎仅用于透明代理
这也提醒各位记得在服...
Xray-core 一直都支持类似于 gost、realm 等软件所谓的“隧道”功能(通过代理协议来端口转发),也就是 dokodemo-door 入站,但是由于当初 v2 起的这个名字不太直观,知道 *ray 还能当“隧道”用的人并不多,导致 dokodemo-door 入站几乎仅用于透明代理
这也提醒各位记得在服...
Tunnel 入站新增
portMap
配置项,可以按本地监听端口指定走代理后的目标地址/端口,优先级高于原有的 address
/port
,已更新 https://github.com/XTLS/Xray-core/pull/4968 正文与配置示例👍18❤2⚡1
GitHub
Release Xray-core v25.8.3 · XTLS/Xray-core
Tunnel inbound: Add portMap config (local listening port -> remote specified address/port) 146b14a #4968 & TLS ECH client improvements #4973 #4949
*ray 一直支持“隧道”即“通过代理协议来端口转发”功能,此前主要由于命名原因(任意...
*ray 一直支持“隧道”即“通过代理协议来端口转发”功能,此前主要由于命名原因(任意...
Tunnel inbound
Latest: https://github.com/XTLS/Xray-core/releases/tag/v25.8.3
本次久违地放出了一些 REALITY NFT 和几个 Project X NFT
请支持一个 REALITY NFT:https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2
如果你有余力,请支持一个 Project X NFT:https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/1
portMap
与 TLS ECH client improvementsLatest: https://github.com/XTLS/Xray-core/releases/tag/v25.8.3
本次久违地放出了一些 REALITY NFT 和几个 Project X NFT
请支持一个 REALITY NFT:https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2
如果你有余力,请支持一个 Project X NFT:https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/1
👍19❤8🔥5
Forwarded from GitHub
💬 New comment on Xray-core#4952 chore: remove vmess from core.
by @RPRX
@gfw-killer 我更新了 VLESS 加密的设计方案,像 QUIC 一样跨二元组复用 sharedKey,兼顾 0-RTT 与前向安全,测试代码已跑通
本周末将正式推出 VLESS 加密,主要特性如下:
- 抗量子的认证与加密,0-RTT
- 前向安全,重放防护
- 更优的性能,且可选 XTLS
全面基于 [ML-KEM-768](https://github.com/XTLS/Xray-core/pull/4992#issuecomment-3156162191)、HKDF(SHA256)、AES-256-GCM/ChaCha20-Poly1305
Reply to this message to post a comment on GitHub.
by @RPRX
@gfw-killer 我更新了 VLESS 加密的设计方案,像 QUIC 一样跨二元组复用 sharedKey,兼顾 0-RTT 与前向安全,测试代码已跑通
本周末将正式推出 VLESS 加密,主要特性如下:
- 抗量子的认证与加密,0-RTT
- 前向安全,重放防护
- 更优的性能,且可选 XTLS
全面基于 [ML-KEM-768](https://github.com/XTLS/Xray-core/pull/4992#issuecomment-3156162191)、HKDF(SHA256)、AES-256-GCM/ChaCha20-Poly1305
Reply to this message to post a comment on GitHub.
👍72❤10🔥9⚡5
这下 PQ PFS 0-RTT 的 VLESS 加密也可选全随机数外观了,基本只 XOR 占比万分之六的 data header,没啥性能成本,唉,全随机数
https://github.com/XTLS/Xray-core/pull/4952#issuecomment-3183275526
https://github.com/XTLS/Xray-core/pull/4952#issuecomment-3183275526
GitHub
chore: remove vmess from core. by Jolymmiles · Pull Request #4952 · XTLS/Xray-core
the goal is to remove the obsolete protocol
🔥30😁11👍6❤2👀1
Forwarded from GitHub
🔨 1 new commit to Xray-core:vless:
84835be: Support VLESS Encryption (native/random) + XTLS Vision + Any Transport like XHTTP (UDS or not) + TLS/REALITY
https://github.com/XTLS/Xray-core/pull/4952#issuecomment-3200720109 by RPRX
84835be: Support VLESS Encryption (native/random) + XTLS Vision + Any Transport like XHTTP (UDS or not) + TLS/REALITY
https://github.com/XTLS/Xray-core/pull/4952#issuecomment-3200720109 by RPRX
👍32🔥5❤3😁1
刚刚 IPv4/TCP/443 正常网站也全挂应该是 GFW 配置错误,现已恢复
这提醒了大家必须要有一个 XHTTP over CDN 备用,有很多 IPv6 可选,也可以 UDP/QUIC,关键时刻防失联
XHTTP 继上次 CF gRPC 时好时坏后,再次证明了自己的价值,赢!
这提醒了大家必须要有一个 XHTTP over CDN 备用,有很多 IPv6 可选,也可以 UDP/QUIC,关键时刻防失联
😁58❤9
👀37😁14❤3
👀18🔥2😁2
Forwarded from GitHub
💬 New comment on Xray-core#4952 chore: remove vmess from core.
by @RPRX
https://github.com/XTLS/Xray-core/commit/ad7140641c44239c9dcdc3d7215ea639b1f0841c 第二版来了,~~也是最终版,感觉又写一套加密人已经麻了~~,MLKEM768X25519 临时密钥交换,中转无限串联,每一级都是基于 X25519 或 ML-KEM-768 认证(最后一级现在可选 X25519 了,公钥很短,~~毕竟未来的量子计算机无法逆转今天的认证~~)
为了避免上版中看似复杂的 XOR 并简化代码,前向安全的密钥交换和 ticket 被 AEAD 了,拿服务端配置才能解,~~虽然也破解不了~~
除了原生外观要不要允许两端先发 padding 消息还要想一下外,~~应该没啥要改的了~~,有兴趣的可以先编译出来测试,晚点 PR
---
服务端配置:(原生外观 / 只 XOR 公钥 / 全随机数。只允许 1-RTT 模式 / 同时允许 1-RTT 模式与 600 秒复用的 0-RTT 模式)
客户端配置:(native/xorpub 的 XTLS 可以 Splice。只使用 1-RTT 模式 / 若服务端发的 ticket 中秒数不为零则 0-RTT 复用)
"mlkem768x25519plus" 代表未来可以无感并联其它密钥交换,"xorpub" 只 XOR 公钥的外观为前面全随机数、后面
支持 XHTTP 等有传输层时的 XTLS,代理 TLSv1.3 时不会二次加密,"random" 全随机数外观后面会只 XOR `23 3 3`,成本极低
Reply to this message to post a comment on GitHub.
by @RPRX
https://github.com/XTLS/Xray-core/commit/ad7140641c44239c9dcdc3d7215ea639b1f0841c 第二版来了,~~也是最终版,感觉又写一套加密人已经麻了~~,MLKEM768X25519 临时密钥交换,中转无限串联,每一级都是基于 X25519 或 ML-KEM-768 认证(最后一级现在可选 X25519 了,公钥很短,~~毕竟未来的量子计算机无法逆转今天的认证~~)
为了避免上版中看似复杂的 XOR 并简化代码,前向安全的密钥交换和 ticket 被 AEAD 了,拿服务端配置才能解,~~虽然也破解不了~~
除了原生外观要不要允许两端先发 padding 消息还要想一下外,~~应该没啥要改的了~~,有兴趣的可以先编译出来测试,晚点 PR
---
服务端配置:(原生外观 / 只 XOR 公钥 / 全随机数。只允许 1-RTT 模式 / 同时允许 1-RTT 模式与 600 秒复用的 0-RTT 模式)
"decryption": "mlkem768x25519plus.native/xorpub/random.1rtt/600s.(X25519 PrivateKey).(ML-KEM-768 Seed)..."
客户端配置:(native/xorpub 的 XTLS 可以 Splice。只使用 1-RTT 模式 / 若服务端发的 ticket 中秒数不为零则 0-RTT 复用)
"encryption": "mlkem768x25519plus.native/xorpub/random.1rtt/0rtt.(X25519 Password).(ML-KEM-768 Client)..."
/
是只能选一个,后面 base64 至少一个,无限串联,使用 ./xray x25519
和 ./xray mlkem768
生成,替换值时需去掉括号 "mlkem768x25519plus" 代表未来可以无感并联其它密钥交换,"xorpub" 只 XOR 公钥的外观为前面全随机数、后面
23 3 3
支持 XHTTP 等有传输层时的 XTLS,代理 TLSv1.3 时不会二次加密,"random" 全随机数外观后面会只 XOR `23 3 3`,成本极低
Reply to this message to post a comment on GitHub.
👍41❤7😁3🎉3⚡2