我对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)时 行为有区别.