Project X Channel
我看到这条消息下面有一些辩论，我的看法是： 1. 中国人已经对付 GFW 十几年了，每个人都积累了大量经验，连我的专用 GitHub 账号都有五年了，而你们才刚开始两年，就觉得自己足够 clever、比我们的大量经验还 clever、不听建议，时间会证明你们的自以为是是错误的 2. 我说过，软件水平不等于反审查水平，同理，面板好用不等于它的反审查能力强，这完全是两回事，在反审查方面应当采纳反审查项目的建议，而非面板项目的建议 3. 虚拟货币的钱包地址本来就是公开的、交易人人可查的，不然就去用隐私币。有人一…
- 明文 HTTP 关键词被阻断
- VPN 协议被封禁
- SS 被主动探测而被封 IP、锱铢必较
- SS 等全随机数流量直接被封 IP
- TLS 被过滤 SNI，甚至有白名单
- TLS 类代理被检测出 TLS in TLS 而被封端口
尤其是在 SS 时代，我们是逐个字节来分析它有没有暴露服务器是代理，有大量锱铢必较的研究，而现在你们直接默认明文 HTTP 访问面板、全盘托出，直接给我们干破防了。所以你们到底有没有反思过为什么知名反审查项目宁愿毁了自己的生态、面板不更新后还要天天说这件事？因为你们这件事干得就特别离谱，让世界各地大量小白踩坑明文 HTTP，把密码、私钥都交给 GFW，已经没有比这更大的安全漏洞了。所以在指责我说你们面板作者受贿并检查钱包地址前，反思一下你们自己错在哪里。我们这边几乎一致认为你们应当禁用明文 HTTP，反思一下自己有什么水平和知名反审查社区一边倒的意见对着干。
👍164😁7❤6🔥3🎉2
Telegram
3.1415 in Project X
纯HTTP明文传密文
其实他们的 GFW 肯定会专门拦截这种奇怪的 HTTP 流量，反而包含密码、私钥的面板流量会被放行，到那时候他们才会明白自己有多天真
或者就 REALITY over Socks5，让审查者以为你在用明文 Socks5 而窃喜、放行并默默记录 SNI，但其实你那 SNI 是假的，我预判了你的预判
或者就 REALITY over Socks5，让审查者以为你在用明文 Socks5 而窃喜、放行并默默记录 SNI，但其实你那 SNI 是假的，我预判了你的预判
😁52👍1
Telegram
YangY🌸 in Project X
隔壁的singbox和mihomo呢
不出意外的话这两个不会跟进 Xray 的任何协议了，他们本来就是面向机场，自建的话建议你选 Xray，路由、负载均衡等订阅今年内会加上
😁33👍12👀1
Telegram
一只住地下的地鼠 | 招affman | 接v2b运维 | cf滥用小王子 in Project X
我还等着sing-box支持xhttp之后把ws换成xhttp
等到下辈子或许能等上，其实 23 年底开始就已经是这样了，当时出了 Vision Seed 的话早就不会还有人以为 sb 还要兼容 Xray 了，可惜没出
😁21
Telegram
Nikita Korotaev in Project X
请问今年是否有计划发布VISION SEED？
我感觉 TUN、VLESS 加密、跨平台客户端、路由及负载均衡订阅很重要
👍34
Telegram
Nikita Korotaev in Project X
其实，要彻底将 Singbox 扔进历史的垃圾堆，只需要 TUN、跨平台应用和类似 SRS 文件的功能（以及从外部来源加载它们）。在服务器端，Xray 无可匹敌，但在客户端的实用性和便利性方面，我们还有提升的空间。
不过这些都会有的，是为了完善 Xray 自身的功能，而不是跟别人比
👍40😁2⚡1
Telegram
Koubi Artúr Szkoufíld in Project X
REALITY 的文章什么时候能公布呢
感觉有文章说明的话能用整合好的方式消除很多疑惑
感觉有文章说明的话能用整合好的方式消除很多疑惑
REALITY 的文章是个悲剧，当时本来想写文章，都怪刚放出代码每天被开十个 issue 问这问那，真的很烦真的很想骂人，还有傻逼要对线，结果我自己关于 REALITY 的说法全分散在各个 issue 以及频道里了，所以 REALITY 的文章不如去找 AI 总结吧，不过还有很多内容我还没说过
👀20😁6❤1
Telegram
空白(🎀ᗜ`‸´ᗜ🌸) in Project X
所以什么时候能稳定下来（
有人 PR 了 race dialer，yuhan 在研究 datagram，我想改 Nginx QUIC
👍17❤4⚡2👀2😁1
Telegram
Nikita Korotaev in Project X
I didn't make any changes. If you see any updates after v2.5.0, they were not made by me.
其实我在想，既然他不写代码了，你能不能去 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
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
😁24
Telegram
M in Project X
U said a few times that iranians told that tls was unstable,this is weird cuase i never had any issues with tls personally,the only thing is some isp have weird sni rules(only some of them) and becuase of that, full random ss or plain http work better(sometimes)…
当我们建议面板删掉明文 HTTP 选项时，这就是一些伊朗人的理由之一
但是你那里 fully random SS 和 plain HTTP 都不封也很难绷啊，毕竟你们那 SS 就是裸奔，密码都被 plain HTTP 面板交给 GFW 了，直接解密
但是你那里 fully random SS 和 plain HTTP 都不封也很难绷啊，毕竟你们那 SS 就是裸奔，密码都被 plain HTTP 面板交给 GFW 了，直接解密
😁30⚡4👀1
Telegram
Frederic Liu in Project X
sb不至于吧，sb更新协议不是蛮快的吗，不过n9i最近忙着搞1.12和1.11的当下版本
不会加就是不会加，原产于 Xray 的协议总想着在其它软件上也能用，你们是有什么 NTR 的癖好吗，他们的实现、更新也是没有任何保证的
你要想安稳用 Xray 的协议就直接用 Xray，别整天想着整花里胡哨的
你要想安稳用 Xray 的协议就直接用 Xray，别整天想着整花里胡哨的
😁30👀4
Telegram
Keith Chai in Project X
是啊，ss2022和vmess都是全加密协议，vless出加密我有点不太理解
VLESS 的加密是抗量子公私钥，且不会增加 RTT，机制类似于 REALITY 的 session id，并且 GFW 拿到客户端公钥没用，服务端私钥不泄露就不会被解密，正好明文 HTTP 面板不更新了不然这私钥是保不住了
🔥32👍7😁6⚡1
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 传私钥是真的蠢
👍38😁2
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
REALITY 的确有 (与 TLS 一致的) 前向安全性
但是 VLESS 的加密层如果采用抗量子加密, 性能 (使用非对称加密) 会有很大损耗
但是 VLESS 的加密层如果采用抗量子加密, 性能 (使用非对称加密) 会有很大损耗
现在的抗量子指的是密钥交换阶段，后面仍是对称加密，不会增加损耗
👍10👀1
Telegram
𝕆𝕓𝕛𝕖𝕔𝕥 𝕊𝕙𝕒𝕕𝕠𝕨 in Project X
量子公钥太大了 以至于难以嵌入到 VLESS 目前所依赖的 TLS Handshake 里
你再去看看，Chrome 的 TLS 已经默认包含 X25519Kyber768 了
并且 VLESS 自身的加密和外层是啥没有关系
并且 VLESS 自身的加密和外层是啥没有关系
👍11
Telegram
O_o $_$ in Project X
但是golang的X25519MLKEM768似乎没搞完🧐
我看了下 Go 1.24 有这个，上述 VLESS 加密有望这几天推出
我现在只担心 Chrome 也改成这个后，已经停更的 uTLS 是个问题
我现在只担心 Chrome 也改成这个后，已经停更的 uTLS 是个问题
👍16🎉2