如何评价这篇博客指出的 XTLS VLESS REALITY 缺陷

[stqfdyr]

https://blog.skk.moe/post/to-kill-a-parrot-detecting-xtls-vless-reality-server/

博客结论：
XTLS VLESS REALITY 的"伪装深度"受限于开发者的工程认知水平，其引以为傲的"回落"机制反而成为精准识别的突破口

据博客作者 sukka 称，他已将亲自合著的论文提交给 华为、派网、新华三、深信服

---

2-17 最新消息

作者表示不认识这个 sukka

吃瓜帖：https://www.nodeseek.com/post-619662-1

这个帖子被管理置为内版，阅读权限只有一天

原作者文章：
https://github.com/acgdaily/papers

[stqfdyr]

我先投降了

[RememberOurPromise]

好像几年前R佬跟klz早就讨论过鹦鹉问题了吧

VLESS-Enc + xtls-rprx-vision + XHTTP(Concurrency) + CDN IPv4/v6 H2/H3 上下行分离 + 优选路线走不同国际出口 + ECH + Browser Dialer 表示：

鉴定为软文

[RememberOurPromise]

等了几个月，就这，我是不满意的，希望继续

[wyx2685]

重点放在人身攻击的技术文章看起来就很搞笑

[Fangliding]

似乎可以通过vmess牌重放过滤器缓解 本来就预留了时间字段

[Fangliding]

就是要变得像vmess一样依赖同步时间了(

[Fangliding]

不对如果在防火墙的角度可以丢弃有效的CH来用以攻击不用重放 那只好和之前的 session ticket 一样启动的时候探测目标行为了 不过这么做会让dest网站知道在用reality

[eatbaba]

稍微认真研究了下这个文章思路，简单从技术上说两点：

第一点：重放 Client Hello 对于有效载荷而成功是没有意义的，重放的第三个（客户端 send）应答包是无法答上来的。无论正常服务器还是 xray tls 都会断开。因此重放并不是在尝试“完成 TLS 握手”，而是在刻意制造“失败的、异常的、半途而废的 TLS 握手”，只为了观察 失败点 的行为差异。

因此，这个poc的思路其实是：

• 只关心：在握手失败之前，服务器能容忍多少个 ChangeCipherSpec，虽然连接最终一定会断，但“断在第几个 CCS”是指纹。

所以整个攻击模型大概是：

ClientHello
CCS
CCS
CCS
...
CCS  → 服务器说：够了，Unexpected Message

记录服务器在“第 N 个 CCS”断开。

看了下，逻辑很简单：

• 1.重放由REALITY 客户端制造的tls hello包，确保走进 Xray 的 REALITY 逻辑（go crypto/tls库）。记录 CCS 值
• 2.直接fallback tls hello包。走源服务器的。记录 CCS 值。

对比CCS差

但是问题在于

ChangeCipherSpec 在 TLS 1.3 中（REALITY 实质外层）是，被废弃、被视为 “non-advancing record”

正常的tls 1.3连接，不会发送额外废弃的CCS数据。而REALITY 客户端，一般不可能发送废弃的CCS数据。

服务端应该可以发现到探测的CCS数据请求。确认这个是探测连接。

不知道被谁设置为隐藏了，算了不掺和这事了

[1PercentSync]

仅从 ChangeCipherSpec 记录来判断是否就是 Reality 也太草率了吧，用了 Go crypto/tls 代码的服务器应用程序理论上也有这个特征，总不能全封了吧

而且考虑到这种识别手段的成本太高了，也不是精准识别，个人认为gfw不会搞这成本高回报低的检测手段

原文的意思是比对回落的ChangeCipherSpec 记录和构造重放攻击的ChangeCipherSpec 记录看是否一致

[jinbasex]

写了很多又删除

还是觉得算了 一个怨妇一样的文章 通篇傲慢态度贬低xray

只能说令人绷不住

[trcrsired]

本来菊花就是邪恶企业。

[hedsbj]

所有的翻墙协议都有缺陷，没有一步到位的协议。时长拉长一点，都会成为历史，但重要的是我们现在能用，非常感谢那群像rprx一样，不断试图穿墙破洞的人。我们能顺利翻墙，正是因为有他们

[RPRX]

如何评价 anytls/anytls-go#19 (comment)