Project X
他的立场真的很令人费解，如果是基于支持anti-censorship应该支持一个更加抗审查的平台或者协议。但按照他的不认为DNS泄漏有风险、支持非xray的平台、但又想要安全的翻墙行为来看，很难分析出他到底什么立场。大致分析可以看出属于滑跪审查一类，类似“我不反对审查，可以放心审查，翻墙也是工作和娱乐需要”，表现出一种对GFW的滑跪。那么既然这样必然会产生我都跪了你们怎么能站着的潜意识，既然都跪了那就要追求跪着体验最好的，比如surge。与二次元滑跪萌萌人有一定相似之处，这类有一种只要我跪的板正态度谦恭铁…
一旦 Xray 出了什么可被识别的问题那就是天大的问题，但即使 SS 专线机场能被直接全部解密那也“没有问题”
刚刚才看到 Sukka 还说我在用 uTLS 之前在模拟 Chrome 指纹时用的是 Go 的 cipher，这都是从哪看的？我咋不知道我还模拟过 Chrome 指纹
Telegram
Project X Channel
看看我们群的讨论风气再看看 SURGE PRO 群
对面秉承着“尬黑一切 RPRX 相关的东西”，到底哪边是邪教一目了然了
这也是为什么我已经不想评价了的原因，对面屁股决定脑袋了讲理没用
对面秉承着“尬黑一切 RPRX 相关的东西”，到底哪边是邪教一目了然了
这也是为什么我已经不想评价了的原因，对面屁股决定脑袋了讲理没用
😁38⚡2
Project X
我觉得大家都知道地球上不存在一种方法或者工具让你作为一个个人能和由国家资源支持的网警对抗，但是这不影响有些工具比另一些工具更好
2017 年：SS 流密码有篡改、解密漏洞，所以 SS AEAD 出现
2021 年：SS AEAD 被我发现“移花接木”漏洞，隔年 SS 2022 出现
2025 年：相同 PSK 且没有前向安全，被解密了又何妨！
GitHub
Shadowsocks AEAD 加密方式设计存在严重漏洞，无法保证通信内容的可靠性 · Issue #183 · shadowsocks/shadowsocks-org
这个问题是昨天发现的，本来我只是想先给 Xray-core 的 Shadowsocks 明文结构加个时间戳以彻底解决对服务端的重放问题。 顺便研究了一下 SS AEAD 的安全性，我脑洞比较大，考虑得比较多，比如是否可以造成 对客户端的攻击，简述如下： 对于 TCP，Shadowsocks AEAD 往返是完全一样的加密结构，HKDF 的 info 也相同，且响应的加密完全独立于请求 对于 ...
😁47👍18👀3⚡1
Project X Channel pinned «倒也有点怪，还是那句话，中国 iOS & macOS 用户占多少？愿意花 700 多去买一个订阅制代理软件的又占多少？我觉得“相关部门”的指示顶多是“保持现状”，至于保持的是什么“解密现状” Xray 被世界上所有有反审查需求的国家/地区的人民广泛使用，尤其是服务端，对面的用户体量有没有 Xray 全球的 1% 都不知道，就这还动不动尬黑 Xray，也就靠个嗓门大，还说我们人少嗓门大 甚至没算中国电信 APP»
Project X Channel pinned «往最远看，回到五年前刚定型 VLESS 设计理念的时候，我的观点就很明确：全随机数协议会被干掉、 Flow Seed 解决内层流量特征问题，两年后 GFW 果真干掉了全随机数协议、开始利用 TLS in TLS 问题 往最近看，去年大力搞 XHTTP，结果帮助了伊朗人民度过了那十二天，去年批评公网明文 HTTP 面板，结果今年 GFW 泄露文件 不过有一说一，还得靠泄露文件有的人才信，离谱他妈给离谱开门了 再近一些，这几年我一直在说 SS 没有“前向安全”，结果 GFW 被爆出有 SS 流量解密模块…»
Project X Channel pinned «哪里令人费解了？从“屁股决定脑袋”的角度出发不就一目了然了？ 一旦 Xray 出了什么可被识别的问题那就是天大的问题，但即使 SS 专线机场能被直接全部解密那也“没有问题” 刚刚才看到 Sukka 还说我在用 uTLS 之前在模拟 Chrome 指纹时用的是 Go 的 cipher，这都是从哪看的？我咋不知道我还模拟过 Chrome 指纹»
Project X Channel pinned «以前是这样的，追求加密安全，今年远不如以前，所以我说礼崩乐坏了 2017 年：SS 流密码有篡改、解密漏洞，所以 SS AEAD 出现 2021 年：SS AEAD 被我发现“移花接木”漏洞，隔年 SS 2022 出现 2025 年：相同 PSK 且没有前向安全，被解密了又何妨！»
Project X
我正好想要一个试试一个没有TLS的协议
建议不要信那些全随机数协议是怎么吹的，再怎么 padding、mux、防主动探测什么的都没用，因为在 GFW 看来全随机数就等于翻墙
另外土制加密协议经常动不动就给你搞出篡改、解密漏洞，就很难蚌
至于 VLESS Encryption，它就四个 go 文件，欢迎任何人审查代码
另外土制加密协议经常动不动就给你搞出篡改、解密漏洞，就很难蚌
至于 VLESS Encryption，它就四个 go 文件，欢迎任何人审查代码
Telegram
Project X Channel
Xray-core v25.9.5 正式版，支持 VLESS Post-Quantum Encryption
或者你也可以使用 Mihomo v1.19.13 ，感谢多次 sync code
VLESS NFT 自成一个系列，每个图片都不同且只有一个，你可以选择自己喜欢的图片来收藏，先到先得
https://opensea.io/collection/vless 首发放出了二十个不同的 VLESS NFT 图片
本次还放出了两个稀缺的 Project X NFT，如果你有余力，请支持一下：htt…
或者你也可以使用 Mihomo v1.19.13 ，感谢多次 sync code
VLESS NFT 自成一个系列，每个图片都不同且只有一个，你可以选择自己喜欢的图片来收藏，先到先得
https://opensea.io/collection/vless 首发放出了二十个不同的 VLESS NFT 图片
本次还放出了两个稀缺的 Project X NFT，如果你有余力，请支持一下：htt…
👍61😁8⚡4🎉2❤1👀1
GitHub
VLESS Reverse Proxy: Forbid reverse-proxy UUID using forward-proxy, e… · XTLS/Xray-core@a83253f
…nabled by default
https://news.1rj.ru/str/projectXtls/1070
https://github.com/XTLS/Xray-core/pull/5101#issuecomment-3567464144
https://news.1rj.ru/str/projectXtls/1070
https://github.com/XTLS/Xray-core/pull/5101#issuecomment-3567464144
防止懒人的 VLESS 反向代理/内网穿透被劫持，VLESS inbound 开了 Reverse Proxy 的 UUID 将默认被拒绝使用正向代理
👍48😁6⚡1🔥1
Project X
网络安全人员接受培训时了解到流量分为三类： 1) 加密且不可读取的流量（约30-40%） 2) VPN和代理流量（所有可实施MITM攻击的配置方案，以及未采用任何流量合法性验证措施的场景（如关闭NgInx、Caddy、Haproxy））（约50-60%） 3) 合法流量（~30-40%） 百分比每周变化，具体取决于地区。 核心要点如下： "若想在CDN中不被发现，请加密并每30秒更换IP地址；若仅需稳定连接，则可直接使用CDN和Reality" 总的来说有3种流量： 1) 加密流量 2) 难以理解且异常的流量…
2) VPN和代理流量（所有可实施MITM攻击的配置方案
😁39🔥2👀1
😁30👍11🔥2👀2❤1
Project X
不idm多线程下载，其实也还好🫣
😁37👀2
Forwarded from GitHub
💬 New comment on Xray-core#2635 Xray会支持歇斯底里2么？
by @RPRX
@shakibamoshiri 我部分支持你的看法，比如说我觉得对 Xray-core 来说，相比于努力引入一个又一个不同的协议但随着时间的推移、后续维护乏力等原因导致跟不上新版本，不如专注于把 VLESS 打造成全场景覆盖的协议并认真维护，显然性价比更高、更可持续
但是有两个例外，一是过于通用的协议，二是 Xray 出站会加被机场普遍使用的协议，Hy2 就属于这种，并且被 Q 麻了危害也不大了
Reply to this message to post a comment on GitHub.
by @RPRX
@shakibamoshiri 我部分支持你的看法，比如说我觉得对 Xray-core 来说，相比于努力引入一个又一个不同的协议但随着时间的推移、后续维护乏力等原因导致跟不上新版本，不如专注于把 VLESS 打造成全场景覆盖的协议并认真维护，显然性价比更高、更可持续
但是有两个例外，一是过于通用的协议，二是 Xray 出站会加被机场普遍使用的协议，Hy2 就属于这种，并且被 Q 麻了危害也不大了
Reply to this message to post a comment on GitHub.
👍35❤6🔥3
Project X
毕竟tls1.2，都在推dh密钥交换处理前向安全了，tls1.3都强制了，18年发布的了...ss2022引入一堆vmess就挺讨人厌的对时啊这些玩意儿...
😁23👀3
Project X
嘛，也就是时过境迁了，嘴上马后炮过过瘾🫣再往前还有ssr的auth chain abc一堆人也觉得很先进（现在对比tls标准也是偏差极大🙈）
加密安全性目前 VLESS Encryption > REALITY > TLS，除非 AES 被破解
VLESS Enc 临时密钥交换强制后量子且 PSK 加密，且联立了 pfs nfs key
VLESS Enc 临时密钥交换强制后量子且 PSK 加密，且联立了 pfs nfs key
❤47👍19🔥4😁1
Forwarded from GitHub
🐛 New issue Xray-core#5347 [Feature Request]
by @sqkam
pre-connect用爽了 期待早日发版
Reply to this message to post a comment on GitHub.
by @sqkam
pre-connect用爽了 期待早日发版
Reply to this message to post a comment on GitHub.
⚡38🔥3👀2
Forwarded from GitHub
💬 New comment on BBS#6 搓了个MITM代理工具，来试试
by @RPRX
> 域名缓存命中的情况下，流量特征将和正常流量无法区分，~~理论上支持亿级域名缓存~~
还需模仿原始 TLS record 分割，如果是避免 TLS in TLS，那么 Go 和 Nginx 的 TLS 还是有一点点区别，比如何时开始不遵守 MTU/MSS
~~还有，代理 MITM 后的明文数据要保证 VPS 完全可信，毕竟你的互联网账号密码 session 什么的都能被 VPS 抓到，我觉得最好不用吧~~
Reply to this message to post a comment on GitHub.
by @RPRX
> 域名缓存命中的情况下，流量特征将和正常流量无法区分，~~理论上支持亿级域名缓存~~
还需模仿原始 TLS record 分割，如果是避免 TLS in TLS，那么 Go 和 Nginx 的 TLS 还是有一点点区别，比如何时开始不遵守 MTU/MSS
~~还有，代理 MITM 后的明文数据要保证 VPS 完全可信，毕竟你的互联网账号密码 session 什么的都能被 VPS 抓到，我觉得最好不用吧~~
Reply to this message to post a comment on GitHub.
❤16👍6