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 的是谁？大家都经历过都看在眼里，无需多言
👍39😁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显然容易混淆
不是完全不能公开而是有选择地公开，用户们用的公钥都是一样的
👍16
Telegram
咪鳩嘈 in Project X
可以这么理解，但是这个 psk 最多 8bytes，如果白名单很满，或者 shortID 普遍很短，这个攻击不难。
啥 short id 相当于 psk，大多数人没设置它，它就是一个后手，防止有人一直过 REALITY 的验证并攻击内层协议而你却不知道他是谁
👍13❤1
Telegram
Secirian in Project X
但是它是pubkey 这个名字足够向用户暗示它是可以完全安全地公开在互联网上的
用脚想都知道你不应该把节点信息公开在互联网上，嫌 GFW 封得慢？
😁39👍2
Telegram
Oops in Project X
如果要从密码学的角度，应该有一个合理的安全模型，然后分析是好是坏。AI 可以帮你做这个。
建议你先研究明白 REALITY 在 TLS 的基础上做了什么、完整流程是什么样的、为什么有底气声称比 TLS 更安全，经典那么多开发者都实现了 REALITY 都没质疑，end user 觉得自己最懂
😁41⚡3❤1
Telegram
ǝɔ∀ǝdʎz∀ɹɔ 👽 in Project X
我个人观点，
他们的加密安全性是一样的/相当的。
tls用于https的时候，本身就是给所有人使用的服务。
reality提供的翻墙服务，本身不是给所有人使用的。特别的，还不能被GFW发现在提供翻墙服务。
他们的加密安全性是一样的/相当的。
tls用于https的时候，本身就是给所有人使用的服务。
reality提供的翻墙服务，本身不是给所有人使用的。特别的，还不能被GFW发现在提供翻墙服务。
REALITY 和 TLS 在数据加密流程、安全性上是一样的，区别在于前者默认免疫证书链攻击，现计划升级抗量子密钥交换后再发 REALITY 的文章
👍15🔥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