Telegram
Idza Jdmx in Project X
大佬 支持windows tun吧 协议稳定没必要频繁更新了 要完善基础设施和生态
Vision Seed & VLESS encryption
Windows Tun & GUI client
Windows Tun & GUI client
👍58⚡11❤6
Project X Channel pinned «Vision Seed & VLESS encryption Windows Tun & GUI client»
Telegram
㍾㍽ ㍼㍻ ㍿ in Project X
话说,sb新出的AnyTLS是新协议吗?和reality比有啥深入浅出的优劣势分析吗,小白能看懂的那种
把 Vision 公开已久的 Seed 拿过去做个协议,还不忘踩 Vision 两脚,属于是给他玩明白了,这还是当初喷 TLS in TLS 是炒作那位吗
😁36❤2🔥1
Telegram
Passingwang🇨🇳🇷🇺🇮🇱 in Project X
sing-box的Any TLS支持也是Any TLS自己写的sing-anytls
人家开小号写的协议,这你都看不出来吗?为什么我第一眼就看出来了
😁32❤1👀1
虽然你是反串但有些事情是自找的,懂的都懂,当初借着喷 TLS in TLS 是炒作的劲头连写两篇智商检测器喷 Xray 的是谁?然后天天找茬 Xray 的是谁?大家都经历过都看在眼里,无需多言
👍38😁14❤1
发现 haproxy QUIC 去年底支持了 BBR,你们可以改它参数试试速度:
https://github.com/haproxy/haproxy/commit/d04adf44dc4f524a02cd74188704cad05d65a98a
https://github.com/haproxy/haproxy/commit/d04adf44dc4f524a02cd74188704cad05d65a98a
GitHub
MINOR: quic: implement BBR congestion control algorithm for QUIC · haproxy/haproxy@d04adf4
Implement the version 3 of BBR for QUIC specified by the IETF in this draft:
https://datatracker.ietf.org/doc/draft-ietf-ccwg-bbr/
Here is an extract from the Abstract part to sum up the the capa...
https://datatracker.ietf.org/doc/draft-ietf-ccwg-bbr/
Here is an extract from the Abstract part to sum up the the capa...
⚡18❤2
Serverless for Iran: Access almost all websites & services directly, for every person in Iran
https://github.com/XTLS/Xray-examples/tree/main/Serverless-for-Iran
Please join the official Xray Iranian group https://t.me/projectXhttp to get the whole working configs
https://github.com/XTLS/Xray-examples/tree/main/Serverless-for-Iran
Please join the official Xray Iranian group https://t.me/projectXhttp to get the whole working configs
🔥32👍4❤3😁3👀2
Project X Channel pinned «Serverless for Iran: Access almost all websites & services directly, for every person in Iran https://github.com/XTLS/Xray-examples/tree/main/Serverless-for-Iran Please join the official Xray Iranian group https://t.me/projectXhttp to get the whole working…»
Telegram
Secirian in Project X
我的意思是非对称加密体系里的pub key就是用来公开的 来个不能公开的pub key显然容易混淆
不是完全不能公开而是有选择地公开,用户们用的公钥都是一样的
👍15
Telegram
咪鳩嘈 in Project X
可以这么理解,但是这个 psk 最多 8bytes,如果白名单很满,或者 shortID 普遍很短,这个攻击不难。
啥 short id 相当于 psk,大多数人没设置它,它就是一个后手,防止有人一直过 REALITY 的验证并攻击内层协议而你却不知道他是谁
👍13❤1
Telegram
Secirian in Project X
但是它是pubkey 这个名字足够向用户暗示它是可以完全安全地公开在互联网上的
用脚想都知道你不应该把节点信息公开在互联网上,嫌 GFW 封得慢?
😁37👍2
Telegram
Oops in Project X
如果要从密码学的角度,应该有一个合理的安全模型,然后分析是好是坏。AI 可以帮你做这个。
建议你先研究明白 REALITY 在 TLS 的基础上做了什么、完整流程是什么样的、为什么有底气声称比 TLS 更安全,经典那么多开发者都实现了 REALITY 都没质疑,end user 觉得自己最懂
😁40⚡3❤1
Telegram
ǝɔ∀ǝdʎz∀ɹɔ 👽 in Project X
我个人观点,
他们的加密安全性是一样的/相当的。
tls用于https的时候,本身就是给所有人使用的服务。
reality提供的翻墙服务,本身不是给所有人使用的。特别的,还不能被GFW发现在提供翻墙服务。
他们的加密安全性是一样的/相当的。
tls用于https的时候,本身就是给所有人使用的服务。
reality提供的翻墙服务,本身不是给所有人使用的。特别的,还不能被GFW发现在提供翻墙服务。
REALITY 和 TLS 在数据加密流程、安全性上是一样的,区别在于前者默认免疫证书链攻击,现计划升级抗量子密钥交换后再发 REALITY 的文章
👍14🔥5😁1
Telegram
Oops in Project X
未免有点太那个,现在又改口一样了?TLS 也能防止证书链攻击,pin 证书就好了。REALITY 的优势更多在白名单审查以及 anti active probe
我就知道这傻逼看不懂人话不会断句,”数据加密安全性“一样,认证流程上比默认比 TLS 更安全,这怎么就不是更安全?谁来把这傻逼踢了
😁22👀4
Telegram
高海 in Project X
把它移除群组了,它要进可再次申请加入
它掰扯到 TLS 也能 pin 证书就实属没茬硬找了,这用法有没有占到 TLS 流量的万分之一都难说,再想到它一开始说公钥看名字就应该公开,真的很难评,吃错药了去公开节点信息?一天天的哪来这么多逻辑鬼才
😁28⚡5❤1👍1
Forwarded from GitHub
💬 New comment on Xray-core#4458 Questioning the Security of the REALITY Protocol
by @RPRX
@gaungap 出来说话
你要知道我写对一个东西的描述就是结论,不是乱写的,分析我当然自己分析过,只是我懒得写出来,我一向如此
就像最早我弄了 VLESS fallbacks,用一堆形容词说明了它相较于 Trojan fallback 的优势,有些人就看不惯,因为我没写分析过程
不想写就是不想写,谁看不懂就是他们自己菜,关我屁事,~~虽然 VLESS fallbacks 的分析后来不小心写了~~
Reply to this message to post a comment on GitHub.
by @RPRX
@gaungap 出来说话
你要知道我写对一个东西的描述就是结论,不是乱写的,分析我当然自己分析过,只是我懒得写出来,我一向如此
就像最早我弄了 VLESS fallbacks,用一堆形容词说明了它相较于 Trojan fallback 的优势,有些人就看不惯,因为我没写分析过程
不想写就是不想写,谁看不懂就是他们自己菜,关我屁事,~~虽然 VLESS fallbacks 的分析后来不小心写了~~
Reply to this message to post a comment on GitHub.
😁11👍4❤1
Forwarded from GitHub
💬 New comment on Xray-core#4458 Questioning the Security of the REALITY Protocol
by @RPRX
然后吧,其实我是欢迎有人 review REALITY 的,我自己设计它的时候也知道它仍有不足,是反审查方面还不够像,而非加密安全问题
但是不能是要求 REALITY public key 公开到互联网上这种 弱智 前提,与 APT-ZERO 说的裸 VLESS 能被 GFW 识别有异曲同工之妙
你提的另一个问题虽然非常刁钻、要求只泄露那部分内存,但能看出你还是有思考的,只是首先你用 AI 翻译出来的第一版牛头不对马嘴,就这我还能看出你在表达什么并指出了你的错误,然而你并没有看懂你错在哪了,并且继续钻牛角尖,就又增加节目效果了
最后我觉得你专门开个小号来发这个 issue 真的很令人反感,这是我非常非常讨厌的事情,因为本身作为 Xray 的开发者,一天天的应付各种水平参差不齐的大聪明们已经够费劲了,还要跟一个没什么结果的小号浪费时间,真的看到小号就想 ban
我经常想,虽然我经常 battle,但结果证明一次次都是浪费时间,况且对方辩输了,接着会有另一个上,甚至小号无所谓,这公平吗
今天你有个 random thought,你开个小号过来跟我辩,你没有任何名誉风险,风险不对等,最后你输了且浪费了我的时间,你下了小号拍拍屁股走人,回到了自己的生活中,逐渐忘掉这件事,明天又有别人开另一个小号,我又要被对方没有任何机会成本地浪费时间
我真的觉得没有任何公平可言,我在这里做事并没有任何显著收益,时间成本都收不回,还要天天应付傻逼,我都觉得自己是傻逼了
Reply to this message to post a comment on GitHub.
by @RPRX
然后吧,其实我是欢迎有人 review REALITY 的,我自己设计它的时候也知道它仍有不足,是反审查方面还不够像,而非加密安全问题
但是不能是要求 REALITY public key 公开到互联网上这种 弱智 前提,与 APT-ZERO 说的裸 VLESS 能被 GFW 识别有异曲同工之妙
你提的另一个问题虽然非常刁钻、要求只泄露那部分内存,但能看出你还是有思考的,只是首先你用 AI 翻译出来的第一版牛头不对马嘴,就这我还能看出你在表达什么并指出了你的错误,然而你并没有看懂你错在哪了,并且继续钻牛角尖,就又增加节目效果了
最后我觉得你专门开个小号来发这个 issue 真的很令人反感,这是我非常非常讨厌的事情,因为本身作为 Xray 的开发者,一天天的应付各种水平参差不齐的大聪明们已经够费劲了,还要跟一个没什么结果的小号浪费时间,真的看到小号就想 ban
我经常想,虽然我经常 battle,但结果证明一次次都是浪费时间,况且对方辩输了,接着会有另一个上,甚至小号无所谓,这公平吗
今天你有个 random thought,你开个小号过来跟我辩,你没有任何名誉风险,风险不对等,最后你输了且浪费了我的时间,你下了小号拍拍屁股走人,回到了自己的生活中,逐渐忘掉这件事,明天又有别人开另一个小号,我又要被对方没有任何机会成本地浪费时间
我真的觉得没有任何公平可言,我在这里做事并没有任何显著收益,时间成本都收不回,还要天天应付傻逼,我都觉得自己是傻逼了
Reply to this message to post a comment on GitHub.
👍33😁9👀3⚡2