Repository navigation
Replies: 2 comments 7 replies
|
请你审计一下Xray-core的代码,开启ECH或REALITY是否有类似问题,裸奔了没有,有什么新发现,可以继续GitHub Security Advisory 报告漏洞 历史真相学家的意义是什么?不觉得是浪费时间吗? |
7 replies
This comment was marked as off-topic.
This comment was marked as off-topic.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment


Uh oh!
There was an error while loading. Please reload this page.
Xray-core 长期以来一直声称其重视安全问题且值得用户信任。然而,它们的实际行径并非如此。如果真的有人报告安全问题,他们会选择瞒天过海。
Xray-core 维护者对代理软件的“跳过证书验证”(即 Xray-core 里的
allowInsecure)或类似的选项嗤之以鼻,认为这相当于没有任何安全措施,会让用户“裸奔”,遭受被中间人攻击的风险。然而,如果是 Xray-core 自己的失误导致用户“裸奔”、被中间人攻击,Xray-core 会当作无事发生。2021 年 10 月 21 日,Xray-core 加入了没有已知问题的
pinnedPeerCertificateChainSha256选项。这意味着双重保险:如果启用此选项,除了执行常规的证书验证逻辑,还会额外执行自定义的固定证书链逻辑。这同时也方便了自签证书的使用:用户可以同时启用allowInsecure以及pinnedPeerCertificateChainSha256,不执行常规的证书验证逻辑,只执行自定义的固定证书链逻辑,安全地使用自签名证书。然而,Xray-core 后来认为
allowInsecure的存在是不安全的,声称启用allowInsecure是在“裸奔”,会让用户被中间人攻击。2026 年 1 月 9 日,Xray-core 为了禁止用户跳过证书验证,防止用户“裸奔”,删除了
pinnedPeerCertificateChainSha256,以新选项pinnedPeerCertSha256取而代之。对于自签名证书,需要同时启用allowInsecure和pinnedPeerCertSha256,不执行常规的证书验证逻辑,只执行自定义的固定证书逻辑,以“安全”地使用自签名证书。然而,pinnedPeerCertSha256存在证书验证绕过漏洞。2026 年 1 月 13 日,Xray-core 发布第一个带有该证书验证绕过漏洞的版本。由于旧选项被删除,用户别无选择,只能迁移到有安全漏洞的新选项。此时,证书验证的防线已经摇摇欲坠。万幸的是,如果不使用自签证书、不启用
allowInsecure,常规的证书验证逻辑至少还能挽救。2026 年 1 月 16 日,Xray-core 作出修改,新选项
pinnedPeerCertSha256始终不执行常规的证书验证逻辑,只执行自定义的固定证书逻辑。这意味着缺少了一层保险:常规的证书验证逻辑永远被跳过,一旦
pinnedPeerCertSha256存在验证绕过漏洞(不幸的是,确实存在),自定义的固定证书逻辑将无法发挥作用,相当于没有任何证书验证措施,可以被成功执行中间人攻击。此时,证书验证的防线已经彻底崩塌。2026 年 1 月 18 日,Xray-core 发布了新版本。此版本的
pinnedPeerCertSha256在大多数时候相当于没有任何证书验证措施。2026 年 2 月 6 日,本人发现 Xray-core 的
pinnedPeerCertSha256存在验证绕过漏洞,并私下向 Xray-core 维护者报告此漏洞的存在。pinnedPeerCertSha256的证书校验逻辑有误,中间人可以在证书链的任意位置插入叶子证书,自定义的固定证书逻辑会校验成功,进而导致中间人攻击得逞。这甚至是一个简单得过分的漏洞,本人没有高深的安全知识,却看一眼代码就能成功发现。既然 Xray-core 长期以来一直声称其对安全问题非常重视,本人原以为 Xray-core 会在短时间修复并向用户披露漏洞的存在。但实际情况令人发指。
当天,Xray-core 偷偷修复了这个证书验证绕过漏洞,提交信息顾左右而言他,声称是在“简化代码”。
当天,Xray-core 发布了新版本,只字不提安全漏洞的存在。用户蒙在鼓里。
更恶劣的是,当天 Xray-core 在其 Telegram 频道发表言论“软件必须从根本上做好安全设计、消除人为因素影响,确保即使是什么都不懂的 endest user 也不至于裸奔”。实际情况呢?由于 Xray-core 糟糕的安全设计,由于 Xray-core 制造的人为因素,用户被迫从安全的旧选项迁移到不安全的新选项,“什么都不懂的 endest user”已经不知情地裸奔了将近一个月。Xray-core 自己才是那个让用户不安全、让用户“裸奔”的人为因素。
Xray-core 本可亡羊补牢,向用户披露安全漏洞的存在,让用户有动机升级修复了安全漏洞的新版本,最大化地降低影响。令人遗憾的是,或许是为了声誉,或许是为了前后言论自洽,它们选择了瞒天过海。
直到 2026 年 7 月 3 日,Xray-core 仍然没有向用户披露漏洞。
2026 年 7 月 3 日,本人发现 Xray-core 对漏洞的修复并不完全,在某些情况下,证书验证依旧可以被绕过。为了避免漏洞被再次恶意隐瞒,只能选择通过 GitHub Security Advisory 报告漏洞。此时,由于 Xray-core 这个人为因素,用户已经不知情地“裸奔”了近半年。
后来,由于本人在群内讨论此话题,某些群友看不过眼,决定要把事情公之于众。Xray-core 依旧死不认错,竟然造出来由于维护者之间的沟通失误而不知道有此漏洞这种荒唐的甩锅临时工式的理由,却又声称发布当天就已经提醒用户有重要修复了,甚至狡辩
pinnedPeerCertSha256是“刚加的没人用的选项”所以这个漏洞没有大的影响。希望更多人认清 Xray-core 糟糕的安全记录,不要被其“重视安全问题”的虚假宣传所欺骗。
以供参考与对比:这是同类项目面对类似的证书验证绕过漏洞的处理措施。
All reactions