Telegram
gh0st in Project X
There has been a lot of news and information about vmess encryption leaks, who else thinks that ss and vmess are secure, I sympathize with you. Vless protocol is not perfect, but with all the features that encrypt it can be so to speak, as the person wrote.
VMess 和 SS 的加密都是对称加密，无前向安全，GFW 拿到客户端密码就能把以前的所有流量都解密了，我几年前就强调过，让我来设计加密的话肯定是 REALITY 这种带公私钥的，REALITY 有 TLS 的前向安全，不过私钥一定不能泄露啊，所以面板明文 HTTP 传私钥是真的蠢
👍37😁2
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
REALITY 的确有 (与 TLS 一致的) 前向安全性
但是 VLESS 的加密层如果采用抗量子加密, 性能 (使用非对称加密) 会有很大损耗
但是 VLESS 的加密层如果采用抗量子加密, 性能 (使用非对称加密) 会有很大损耗
现在的抗量子指的是密钥交换阶段，后面仍是对称加密，不会增加损耗
👍9👀1
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
量子公钥太大了 以至于难以嵌入到 VLESS 目前所依赖的 TLS Handshake 里
你再去看看，Chrome 的 TLS 已经默认包含 X25519Kyber768 了
并且 VLESS 自身的加密和外层是啥没有关系
并且 VLESS 自身的加密和外层是啥没有关系
👍10
Telegram
O_o $_$ in Project X
但是golang的X25519MLKEM768似乎没搞完🧐
我看了下 Go 1.24 有这个，上述 VLESS 加密有望这几天推出
我现在只担心 Chrome 也改成这个后，已经停更的 uTLS 是个问题
我现在只担心 Chrome 也改成这个后，已经停更的 uTLS 是个问题
👍16🎉2
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
好 明白了 最开始误解了
我以为是给 VLESS 单独添一个加密层
我以为是给 VLESS 单独添一个加密层
是单独添一个加密层，目前决定用抗量子的 X25519MLKEM768
1-RTT 的话有前向安全，0-RTT 的话私钥不泄露也是安全的，别明文传
1-RTT 的话有前向安全，0-RTT 的话私钥不泄露也是安全的，别明文传
👍14🎉1👀1
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
私钥不泄漏确实是安全的
但是如果采用了 TLS13 的会话恢复 如何应对重放?
但是如果采用了 TLS13 的会话恢复 如何应对重放?
我觉得倒是可以设计成会话恢复，至于防重放很简单，我本来在 SS 那边说的是给明文结构加个时间戳，但这个被 SS2022 用了我就不想用了，我觉得我可以发明一个滑动窗口防重放、无需对时
还有 VLESS 加密只考虑加密安全，不考虑对付 GFW，这不是它的用途
还有 VLESS 加密只考虑加密安全，不考虑对付 GFW，这不是它的用途
👍17😁2👀2
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
滑动窗口 无需对时🤔怎么说?
比如说只记录 100 个连接头以防重放，一开始是第 1-100 条连接，后面慢慢滑到第 201-300 条连接，小于 201 的就直接扔了，无需对时
👍12
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
我的意思不是避免重放带来的影响
而是如何向重放方应答 以免暴露
而是如何向重放方应答 以免暴露
都 2025 年了还想着用非 TLS 加密过墙呢？VLESS 加密不是给 GFW 看的
😁17
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
stateful 不是恰当的实现方法
假如服务端会重启?
假如服务端会重启?
你在群里的一系列发言有点雷人，因为你想错了，我们说的窗口都是依附于第一次的完整握手，肯定不是整个服务器共用的
👍8
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
但是这我也不好理解
TLS 已经做防重放了
TLS 已经做防重放了
TLS 的 0-RTT 不防重放，上层 HTTP GET 时才会用，POST 不会用
👍7
Telegram
风扇滑翔翼 in Project X
我的意思是滑都不用滑 只需要记忆一个票据下的已用的id就行了 开销很低
缺点就是有复用次数限制，其实滑起来也很简单，比如只允许最新序号减 100 以内的包，每次收到序号更大的包就 range map 把该请的清掉
或者固定时间比如每一分钟清一次，这样开销就更低了，可以忽略不计
或者固定时间比如每一分钟清一次，这样开销就更低了，可以忽略不计
👍9
Project X Channel pinned «我看到这条消息下面有一些辩论，我的看法是： 1. 中国人已经对付 GFW 十几年了，每个人都积累了大量经验，连我的专用 GitHub 账号都有五年了，而你们才刚开始两年，就觉得自己足够 clever、比我们的大量经验还 clever、不听建议，时间会证明你们的自以为是是错误的 2. 我说过，软件水平不等于反审查水平，同理，面板好用不等于它的反审查能力强，这完全是两回事，在反审查方面应当采纳反审查项目的建议，而非面板项目的建议 3. 虚拟货币的钱包地址本来就是公开的、交易人人可查的，不然就去用隐私币。有人一…»
Project X Channel pinned «新的一天，新的 PUA，我们的反审查之路，经历了： - 明文 HTTP 关键词被阻断 - VPN 协议被封禁 - SS 被主动探测而被封 IP、锱铢必较 - SS 等全随机数流量直接被封 IP - TLS 被过滤 SNI，甚至有白名单 - TLS 类代理被检测出 TLS in TLS 而被封端口 尤其是在 SS 时代，我们是逐个字节来分析它有没有暴露服务器是代理，有大量锱铢必较的研究，而现在你们直接默认明文 HTTP 访问面板、全盘托出，直接给我们干破防了。所以你们到底有没有反思过为什么知名反审查项目宁…»
GitHub
Xray-examples/MITM-Domain-Fronting at main · XTLS/Xray-examples
Some examples of uses for Xray-core. Contribute to XTLS/Xray-examples development by creating an account on GitHub.
这下 Xray 也开始无需代理、直连网站了（最适合伊朗）：https://github.com/XTLS/Xray-examples/tree/main/MITM-Domain-Fronting
https://github.com/XTLS/Xray-core/commit/9b7841178a4cb7d5b7ce558afa221254d8d3fa56
https://github.com/XTLS/Xray-core/commit/9b7841178a4cb7d5b7ce558afa221254d8d3fa56
🔥22
Telegram
xiaohuangbo im_furry_data in Project X
你这也太麻烦了，早就有图形化界面PixCealer对小白用户十分方便友好的域前置工具了
这与 core 无关，既然现在 Xray 支持了先 MITM 再发假 SNI 再校验指定域名证书，图形化界面就是 2dust 要考虑的事情了，你们快建议他去写
😁23👍3⚡2
Telegram
xiaohuangbo im_furry_data in Project X
对，GFW有时候并没有封IP，而是通过读取SNI来判断你访问了哪个网站，我曾经就在校园网内（代理会被发现喝茶）就用域前置来查维基百科，看谷歌和V2EX的（
😁22❤1