摘要

  • 加密的 ClientHelloInner、外层信封和面向客户端服务器的 public_name 分属不同证据层；public_name 不是私有后端的名称。
  • ECH 接受、DNS 配置、TLS 证书验证和应用成功各自回答不同问题，不能彼此借用结论。

RFC 9849 把握手开头分成两份。客户端将私有值放在 ClientHelloInner 中，把无敏感性的值和 ECH 扩展放在 ClientHelloOuter 中，再用 ECH 公钥加密内部消息。外层与内层通过附加认证数据绑定，攻击者不能任意改动外层并保留同一个内层。这是信封完整性的一个重要性质，却没有把 DNS 记录、公开地址、前端服务商、私有后端和应用主体写成同一个实体。

public_name 正是最容易被夸大的字段。RFC 将其定义为面向客户端的服务器的 DNS 名称：该服务器受信任可更新 ECH 配置，也能帮助客户端从陈旧配置中恢复。客户端通常把它放进外层 SNI。它是公开的路由与恢复表面，不是隐藏后端的名称，不是所有私有名称的所有权声明，也不是身份验证的结论。

两种拓扑说明了为什么必须克制。共享模式中，面向客户端服务器和 TLS 终止端可能是同一方；分离模式中，前端向终止 TLS 的后端转发，前端并不看到连接明文。RFC 对分离模式假定前后端间有认证通道，并假定攻击者无法关联两段流量；防关联的具体机制明确不在规范范围内。因此，看见 ECH 不能审计这些部署前提是否成立。

“接受 ECH”也只是有限状态。服务器可以接受并使用内部 ClientHello，或拒绝并使用外部 ClientHello。拒绝后，该连接不能供 ECH 客户端传输应用数据，客户端可能获得新的配置并重试。接受只说明协议在这次握手中选择了内部路径；它不说明本地信任库接受了证书链、预期名称已匹配、应用授权了请求，或用户所需的交易成功了。

RFC 8446 保留了这条边界：TLS 协商参数、可认证对端并建立密钥，但它不定义应用语义。信任锚独立分发，证书验证的详细规则也不完全属于 TLS。反过来，ECH 不能替代证书验证。RFC 9460 的 SVCB/HTTPS 记录同样只是客户端的连接指令：它们可携带公钥和替代端点，且端点可能能力不同、运营者不同。一条记录不能证明最终选中了哪个端点，更不能证明服务结果。

调查记录应把 ECHConfig 来源和 TTL、解析器与缓存、接受/拒绝、预期身份和本地验证、前后端通道、实际端点与应用结果分栏保存。加密报文能回答其中一栏，不应被强行改写成其余栏的事实。

来源