Project X Channel
18.3K subscribers
24 photos
1 file
609 links
Download Telegram
其实他们的 GFW 肯定会专门拦截这种奇怪的 HTTP 流量,反而包含密码、私钥的面板流量会被放行,到那时候他们才会明白自己有多天真

或者就 REALITY over Socks5,让审查者以为你在用明文 Socks5 而窃喜、放行并默默记录 SNI,但其实你那 SNI 是假的,我预判了你的预判
😁50👍1
小火箭的作者已经实现了,不知道啥时候上,可能还在等协议稳定下来
👍35😁71
不出意外的话这两个不会跟进 Xray 的任何协议了,他们本来就是面向机场,自建的话建议你选 Xray,路由、负载均衡等订阅今年内会加上
😁32👍11👀1
等到下辈子或许能等上,其实 23 年底开始就已经是这样了,当时出了 Vision Seed 的话早就不会还有人以为 sb 还要兼容 Xray 了,可惜没出
😁19
今年内的话应该是能排上的,毕竟 yuhan 已经写好了代码就等 review

我感觉 TUN、VLESS 加密、跨平台客户端、路由及负载均衡订阅很重要
👍33
REALITY 的文章是个悲剧,当时本来想写文章,都怪刚放出代码每天被开十个 issue 问这问那,真的很烦真的很想骂人,还有傻逼要对线,结果我自己关于 REALITY 的说法全分散在各个 issue 以及频道里了,所以 REALITY 的文章不如去找 AI 总结吧,不过还有很多内容我还没说过
👀19😁51
有人 PR 了 race dialer,yuhan 在研究 datagram,我想改 Nginx QUIC
👍1742👀2😁1
其实我在想,既然他不写代码了,你能不能去 PR 一个 127.0.0.1 并详细说明为什么不能允许用户通过明文 HTTP 访问面板、不能留下该选项
👍17🔥2😁1👀1
Forwarded from Masoud
Interesting😁If the translation is correct
a few months ago when I was discussing the blocking of Reality by Iran's GFW in a group someone told me to use Reality through a SOCKS5, and it wouldn't get blocked
😁23
其实这就是他们的 GFW 倾向于逼他们使用明文以记录流量的证据之一

https://t.me/projectXtls/793

就这他们还以为明文好、GFW 不管呢
😁231
当我们建议面板删掉明文 HTTP 选项时,这就是一些伊朗人的理由之一

但是你那里 fully random SS 和 plain HTTP 都不封也很难绷啊,毕竟你们那 SS 就是裸奔,密码都被 plain HTTP 面板交给 GFW 了,直接解密
😁294👀1
不会加就是不会加,原产于 Xray 的协议总想着在其它软件上也能用,你们是有什么 NTR 的癖好吗,他们的实现、更新也是没有任何保证的

你要想安稳用 Xray 的协议就直接用 Xray,别整天想着整花里胡哨的
😁29👀4
安卓上 NG 不够你用吗,iOS 上更是一堆软件是 Xray-core,怎么就少了
👍26😁7
VLESS 的加密是抗量子公私钥,且不会增加 RTT,机制类似于 REALITY 的 session id,并且 GFW 拿到客户端公钥没用,服务端私钥不泄露就不会被解密,正好明文 HTTP 面板不更新了不然这私钥是保不住了
🔥32👍7😁61
VMess 和 SS 的加密都是对称加密,无前向安全,GFW 拿到客户端密码就能把以前的所有流量都解密了,我几年前就强调过,让我来设计加密的话肯定是 REALITY 这种带公私钥的,REALITY 有 TLS 的前向安全,不过私钥一定不能泄露啊,所以面板明文 HTTP 传私钥是真的蠢
👍37😁2
你再去看看,Chrome 的 TLS 已经默认包含 X25519Kyber768 了

并且 VLESS 自身的加密和外层是啥没有关系
👍10
我看了下 Go 1.24 有这个,上述 VLESS 加密有望这几天推出

我现在只担心 Chrome 也改成这个后,已经停更的 uTLS 是个问题
👍16🎉2