摘要

  • SNI 让客户端在 TLS ClientHello 中提前报出目标 DNS 名称，服务器于是能在加密的 HTTP 请求到达之前，从共享地址上选择正确证书与服务配置。
  • 这个名称只是选路提示，不是身份或权限证明。它位于加密之前，因此可被路径上的观察者看见；ECH 后来用“公开外层名称 + 加密内层名称”重新分配可见性。

一张证书要回答一个尚未解密的问题

设想一台前端服务器只有一个地址，背后放着四个 HTTPS 网站。客户端连上来后，服务器马上要决定拿出哪张证书。可真正说明访问目标的 HTTP Host 字段，此时还封在未来的加密请求里；TLS 握手没有结束，服务器根本不能读它。

这形成了一个顺序上的死结：先有证书和密钥，才能保护 HTTP；先知道 HTTP 中的站点名称，才能选对证书。RFC 2246 所定义的 TLS 1.0 正是先完成认证与密钥协商，再传送受保护的应用数据。名称不是不存在，而是到得太晚。

2003 年的 RFC 3546 给出了 Server Name Indication。客户端在 ClientHello 中提前放入服务器名称；同一网络地址上的虚拟服务器便可据此选出合适的证书、安全参数和后端服务。

SNI 的历史意义不只是增加一个字段，而是把字段放在一个极其有效、也极其敏感的位置：早到足以影响握手，早到尚未受到这次握手的加密保护。

共享地址不必再共享一种身份

普通 HTTP 的按名称虚拟主机很自然。请求抵达后，前端读取权威主机名，再把流量交给相应站点。TLS 把读取动作挡在加密之后，使同一个地址上的不同站点在握手开始时看起来完全相同。

没有 SNI 时，运营者往往只能给每种证书身份分配地址，把许多名称塞入同一证书，或让所有陌生连接先拿到默认配置。这些办法都把地址资源、证书生命周期和托管拓扑不必要地捆在一起。

SNI 解除了一部分捆绑。DNS 与路由仍把连接送到一个地址；ClientHello 又提供一个更细的名称选择器。共享主机、CDN、反向代理和后来的云入口可以让许多独立站点共用接入面，却各自保持证书和策略。

地址并没有失去作用。它决定连接去往哪个边缘；SNI 决定这个边缘应启动哪套 TLS 上下文。两者是不同层次的选择。

写在外面的收件名不是签名

RFC 6066 后来统一了扩展规范。server_name 是 ClientHello 中的名称列表，常用的 host_name 表示 DNS 主机名。服务器若理解扩展却不认识该名称，可以发出 unrecognized_name 警报中止，也可以继续握手。

允许继续这一点，恰好说明 SNI 不是什么。它不是客户端资格证明，不保证 DNS 没被操纵，也不证明即将返回的证书对该名称有效。客户端仍要独立验证证书；应用仍要判断账户和请求权限；后来的 HTTP 权威也不能因为 SNI 出现就免于核对。

它更像信封外面的收件部门。门房借此把信件送到正确柜台，但真正的签名、内容和许可在别处验证。把选路名称误当授权，会使默认主机、跨租户转发和证书范围都变成隐患。

有用的位置造成了可见性

在 TLS 1.2 及更早的结构里，ClientHello 先于握手生成的加密密钥。服务器不可能用一个尚未解密的名字去选择解密它所需的配置。SNI 以明文换取可用的先后顺序。

于是，观察者可能看不见 HTTP 路径、正文和响应，却仍能从 ClientHello 读到目标站点。RFC 8744 系统记录了明文 SNI 带来的隐私泄露，也记录了网络管理、过滤与审计对这个字段形成的依赖。

这不是某个实现忘记打开加密，而是协议位置产生的结果。名称进入了连接建立的公开阶段，沿途系统就能分类、留存甚至阻断它。

RFC 8446 的 TLS 1.3 加密了 ServerHello 之后的大部分握手，但最初的 ClientHello 仍需先抵达服务器。SNI 的早期选择作用继续存在，隐私问题也没有自动消失。

可见字段会长出利益相关者

一个字段一旦稳定可见，基础设施就会围绕它生长。托管平台按它分流，监控系统按它统计，安全设备按它制定策略，故障排查也借它区分共用地址的服务。用途可能合理，结果却相同：路径上的第三方获得了目的名称。

因此，加密 SNI 不只是“再包一层密文”。服务前端仍要得到足够的公开信息，才能选择能够解开内层 ClientHello 的配置。与此同时，依赖明文名称的设备会把失去可见性表现为兼容性或治理冲突。

SNI 由此形成一条路径依赖：共享 HTTPS 需要早期名称；早期名称催生运营用途；运营用途又提高隐藏名称的迁移成本。

ECH 把公开入口与私密目的地分开

2026 年的 RFC 9849 规定 Encrypted ClientHello。客户端准备一份包含敏感信息的内层 ClientHello，再把它加密封装进外层 ClientHello。外层携带可以公开的服务名称，把连接送到支持 ECH 的前端；真实源站名称留在加密内层，只有隐私边界内的服务才能读取。

ECH 没有让元数据消失。网络地址仍然可见，外层公开名称也刻意可见。改变之处在于：为了把连接送到提供商入口，不再必然暴露用户最终访问的源站名称。

协议还要求清楚处理接受、拒绝和重试。客户端需要从受保护的握手确认 ECH 是否真正生效；服务器若无法解密，可以提供新的重试配置。外层名称不是默认源站，更不能在失败时悄悄取代用户原本的访问权威。

这是一种更精细的顺序安排：先公布抵达隐私前端所需的最小名称，再在那道边界内揭示真正目的地。

一个字段改变了 HTTPS 的成本，也留下边界债务

SNI 让 TLS 的证书选择顺序适应了按名称共享的 Web。它使一个地址承载多个安全身份成为常规能力，减少了地址、证书与物理入口之间的僵硬绑定，是 HTTPS 普及的重要基础条件。

它从未自行认证名称，从未授予应用权限，也从未承诺向网络隐藏目的地。同一个位置同时带来规模优势与隐私代价：放在保护之前，服务器才能及时使用；放在保护之前，观察者也能及时使用。

ECH 延续的并非“所有名称都不可见”的幻想，而是最小披露原则。协议设计真正决定的是谁在什么阶段必须知道哪个名称。时间位置就是权力位置。

来源与证据限制

本文依据 RFC 2246、RFC 3546、RFC 6066、RFC 8446、RFC 8744 与 RFC 9849。关于托管成本、监控激励和迁移路径依赖的分析，是从消息顺序与字段可见性推导出的结构判断，不代表某个国家或供应商的统计结果。