原文链接：VLESS 相关漏洞报告
This topic created in 63 days ago, the information mentioned may be changed or developed.
 |
1
mynameisK May 11 via iPhone
没看懂 云里雾里的
|
 |
2
zxbiao May 11 via Android
问下 chatgpt 就能知道答案了
|
 |
3
snylonue May 11  1
|
 |
4
383394544 May 11 via iPhone
第四次忍界大战开始了，有人要用 llm 复活之前隐退的大佬参战吗？
|
 |
5
pagxir May 11 via Android
因为写这个的人，连基本概念都没搞清楚。标题写的是 vless ，内容写的是 xtls
|
 |
6
nizhong044 May 12 via Android
这是个好事儿啊
|
 |
7
x86 May 13
R 主席怎么说？昨天删了库
|
 |
8
txican 12 days ago
我对 VLESS-Reality-cracker 的测试方案的观点
VLESS-Reality-cracker 的核心思路是: 如果被测试的 TLS 服务端是 Reality 服务端, 那么 重放抓包的 client-hello 数据包(1) 和 发送 {基于数据包(1)修改了 sessionID} 的数据包 会使得随后发出的探针数据包被不同的 TLS 系统处理, 一个是 Reality 服务端的 TLS 系统, 一个是"偷"证书的域名所在的 TLS 系统. 预期的测试结果是, 探针在两轮测试中得到的返回结果会不同. 从反面讲, 如果被测试的 TLS 服务端是"正常"TLS 服务端, 那么 探针在两轮测试中得到的返回结果会一致. 我的思考 如果一个探针能测试出来 Reality 服务端与"偷"证书的域名所在的 HTTPS 服务端(下称 target)的行为差别, 那么 搭建 Reality 服务端的人, 可以用这个探针测试 target, 得到结果后, 修改/配置 Reality 服务端, 使得 Reality 服务端在面对这个探针时, 作出与 target 一致的行为. 从而避免 Reality 服务端被这个探针检测. 考虑到流行的 TLS 系统不是无穷的, 那么 针对这些 TLS 系统的行为设计的探针, 数量/种类 不是无穷的. 我们可以设计尽可能多的探针来覆盖尽可能多的流行 TLS 系统. 然后用这些探针测试你准备"偷"证书的域名(target), 将得到的结果 配置到 Reality 服务端. 之后, 当 Reality 服务端再遇到探针时, 就可以作出与 target 同样的行为了. 在这样的前提下, 攻击方能成功判定 Reality 服务端的条件是: 攻击方掌握了一个你没有提前测试过的探针, 并且这个探针在测试 Reality 服务端和"偷"证书的域名(target)时 行为有区别. source: https://zelikk.blogspot.com/2026/05/vless-reality-cracker.html |
Select Language