什么是 REALITY？

传统的 TLS 包裹式隧道需要一个域名和一份证书。这个需求带来一连串细小的信号，单独看没有一个是致命的，但合在一起就足以让端点被识别出来。

• 域名是注册过的，而注册是一条公开记录，带有日期、注册商，而且往往与为同一目的创建的其他域名共享某种模式。
• 公共受信任的证书会被发布到 Certificate Transparency 日志中，任何人都能检索。一个域名的证书历史并不私密。
• 域名必须解析到端点地址，于是两者在 DNS 中被永久地绑定在一起。
• 主机名在握手中以明文声明，因此可以与列表做匹配。
• 最具决定性的一点：如果某个系统在没有有效凭据的情况下自己去连接这个端点，粗糙的服务器会表现出任何普通 Web 服务器都不会有的行为。

这些都可以缓解——用一个有年头的域名、选一家审查较松的证书颁发机构、让域名远离公开列表。但没有一条能被消除，因为一台为自己的域名持有自己证书的服务器，按定义就是一个可被找到的独立实体。

REALITY 把问题反了过来。它不去申请一份之后还得设法弄得人畜无害的证书，而是借用一个真实、无关、热门网站的身份——而当任何没有有效凭据的人连上来时，就把那个真实网站交给他。

1. 1

   客户端声明一个真实站点

   它发起 TLS 握手，指名运营方选定的某个合法的高流量域名。在观察者看来，这就是对一个普通站点的一次普通访问。

2. 2

   服务器转发到那个真实站点

   端点把握手转发给真正的目的地，于是返回的证书就是该站点的真实证书，签名有效，并且拥有真实的 Certificate Transparency 历史。从未有任何证书为这条隧道签发过。

3. 3

   获授权的客户端在握手内部证明自己

   持有运营方密钥的客户端，会把一个认证值嵌入握手本就携带的字段中。既没有额外消息，也没有额外往返；观察者只看到一次正常的交换。

4. 4

   路径就此分岔

   识别出有效客户端后，服务器接管会话并承载隧道。看到其他任何东西——浏览器、扫描器、探测器——它就继续转发，访客也就只是到达了那个真实网站。

最后两行很重要。REALITY 是针对「通过握手识别」和「通过探测识别」的有力回应。它对因其他原因被列入封锁名单的地址无能为力，对「多少流量流向何处」的统计分析也同样无能为力。任何把它说成完整解决方案的描述，都夸大了。

• 被借用站点的选择关系重大。它必须热门到访问它不引人注目，从该网络的角度看是个合理的目的地，并且从端点可达。选得不好，本身就是一个信号。
• 这里也有伦理层面的问题：被借用站点的名字是在其不知情、未参与的情况下被使用的。除了它本来就准备应答的那些握手之外，它并不代你承载任何流量，但应当明确说清楚这个设计做的就是这件事。
• 对于干脆把被借用站点整个封掉的运营方，或者只放行一份明确目的地清单的网络，它提供不了保护。
• 与所有这类设计一样，它是对当下存在的分类器的回应。检测方面的研究不会停止，对它的回应也不会。

看待 REALITY 的合理方式，是把它视为大幅抬高了识别一个端点的成本，而不是视为隐形。它令人信服地堵上了证书和探测这两条路。它没有堵上的那些路，依然敞开着。