在 TLS 1.3 协议中，尽管服务器证书和大部分握手消息已被加密，但客户端发送的第一个消息 ClientHello 中仍然包含明文的 Server Name Indication（SNI）扩展，这一字段直接暴露了客户端正在访问的目标域名。RFC 9849 定义的 Encrypted Client Hello（ECH）机制通过在握手阶段加密 SNI 与其他敏感扩展，实现了 TLS 隐私增强的工程化路径。本文从协议设计出发，结合工程实现细节，阐述 ECH 的核心机制与落地要点。
隐私泄漏背景与 ECH 设计目标
传统的 TLS 握手流程中，客户端在 ClientHello 消息的 SNI 扩展中明文填写目标服务器域名，网络上的任何观察者都可以据此判断用户正在访问的具体网站。这一泄漏在多租户托管环境中尤为敏感 —— 同一个 IP 地址可能承载数十甚至数百个不同的域名，SNI 成为识别目标服务器的唯一显式信号。ECH 的核心设计目标正是对 SNI 以及其他敏感扩展（如 ALPN 列表）进行加密，使得即使攻击者处于网络路径上，也无法从 ClientHello 中获取目标域名信息。
RFC 9849 将这一机制的形式化安全目标定义为三个层次：首先是安全属性保持，即使用 ECH 不应削弱 TLS 1.3 原有的安全属性；其次是握手隐私，同一匿名集合内的服务器名称应对被动观察者不可区分；最后是降级抵抗，攻击者无法将尝试使用 ECH 的连接降级为不使用 ECH 的连接。这些目标通过双层 ClientHello 结构、HPKE 加密和确认信号机制得以实现。
双层 ClientHello 架构与加密流程
ECH 引入了一个关键设计：将传统的单个 ClientHello 拆分为两个结构 ——ClientHelloInner（加密内部版本）和 ClientHelloOuter（明文外部版本）。客户端实际发送的是 ClientHelloOuter，其中包含一个特殊的 encrypted_client_hello 扩展，该扩展承载了加密后的 ClientHelloInner。这种设计使得网络观察者只能看到 ClientHelloOuter 的内容，而真正的目标域名和偏好设置被安全地封装在加密负载中。
在构造阶段，客户端首先构建完整的 ClientHelloInner，其中包含真实的 SNI 值、ALPN 列表和其他敏感扩展。随后，客户端对该消息进行填充并使用 HPKE（Hybrid Public Key Encryption，RFC 9180）进行加密。HPKE 结合了前向安全的密钥封装机制（KEM）、密钥派生函数（KDF）和认证加密算法（AEAD），提供了成熟的公钥加密框架。加密时使用的公钥来自服务器发布的 ECH 配置，而密文则作为 encrypted_client_hello 扩展的 payload 字段发送。
与此同时，客户端构造一个表面上看似正常的 ClientHelloOuter，其中的 SNI 扩展被替换为服务器发布的公共名称（public_name）。这个公共名称是服务器公开可访问的域名，用于 ECH 被拒绝时的回退认证。ClientHelloOuter 的其他字段（如密码套件列表、TLS 版本等）可以与 ClientHelloInner 相同或不同，但关键敏感信息必须仅存在于加密的内部版本中。
ECH 配置结构与密钥管理
服务器通过发布 ECH 配置（ECHConfig）来声明其 ECH 能力。该配置是一个结构化的数据对象，包含版本号、长度字段以及具体的配置内容（ECHConfigContents）。配置内容中最重要的字段是 key_config，它携带了 HPKE 公钥和相关元数据。具体而言，key_config 包含一个字节长的 config_id 标识符、密钥封装机制标识符（kem_id）、公钥本身以及支持的密码套件列表（KDF 和 AEAD 配对）。
config_id 的设计允许服务器在单个连接中快速识别使用哪个密钥配置。当客户端发送 ECH 请求时，它在 encrypted_client_hello 扩展中携带所选配置的 config_id，服务器直接据此定位对应的私钥进行解密，无需遍历所有已知配置。服务器应当为每个活跃配置分配唯一的 config_id，并保留历史配置以处理客户端缓存的过期配置。推荐的做法是通过随机采样避免冲突，直到选出一个与已知配置不重复的值。
ECH 配置的发布机制由 RFC 9848 规范，推荐通过 DNS SVCB 或 HTTPS 记录进行分发。这意味着客户端在进行域名解析时即可获取服务器的 ECH 公钥信息，从而在建立 TLS 连接前完成加密准备。需要注意的是，ECH 本身并不要求 DNS 认证 —— 在没有 DNSSEC 保护的环境中，攻击者可以替换 ECH 配置，但这一限制与 DNS 本身的脆弱性一致，无法通过传输层加密单独解决。
客户端实现要点
客户端实现 ECH 需要特定的构建规则遵循。首先，客户端必须仅支持 TLS 1.3 或更高版本进行 ECH 握手，因为 ECH 依赖于 TLS 1.3 的握手结构和加密原语。其次，ClientHelloInner 中禁止包含 TLS 1.2 或更早版本的协商信息，也不应包含用于恢复 TLS 1.2 会话的票据。这些限制确保了后端服务器不会协商与 ECH 不兼容的 TLS 版本。
填充策略是 ECH 隐私属性的关键组成部分。客户端需要根据 RFC 9849 建议的填充方案对 ClientHelloInner 进行处理，以防止通过密文长度推断明文内容的侧信道泄漏。具体而言，每个扩展应当根据服务器匿名集合中最长的可能值进行填充 —— 例如，ALPN 扩展应填充为所有应用配置中最长的 ALPN 列表长度；SNI 扩展则利用 ECH 配置中的 maximum_name_length 字段指导填充。最终，整个消息的长度应当对齐到 32 字节的倍数，进一步模糊不同客户端之间的差异。
当服务器拒绝 ECH 时（例如服务器不支持或配置不匹配），客户端需要执行回退流程。服务器在拒绝 ECH 时会在 EncryptedExtensions 中返回 retry_configs，其中包含更新的 ECH 配置。客户端可以使用这些新配置重试连接，而无需发起新的 DNS 查询。如果服务器明确禁用了 ECH（通过返回不带 retry_configs 的拒绝），客户端应在后续连接中禁用 ECH。
服务器端处理流程
服务器在接收 ClientHello 后，首先检查是否存在 encrypted_client_hello 扩展。如果不存在，服务器按传统方式处理连接。如果存在，服务器根据扩展中的 config_id 定位对应的 ECH 配置和私钥，尝试使用 HPKE 解密 payload。如果解密成功，服务器从解密结果中重建 ClientHelloInner，并将其转发给后端服务器进行后续处理。
在分离模式（Split Mode）部署中，客户端面向服务器（Client-Facing Server）和后端服务器（Backend Server）是物理分离的两个实体。客户端面向服务器负责解密 ECH 扩展并提取 ClientHelloInner，然后将其转发给实际的目标后端服务器。后端服务器则像处理普通 TLS 连接一样处理 ClientHelloInner，并通过特定的确认信号向客户端表明 ECH 已被接受。这一确认通过在 ServerHello.random 的最后 8 字节中嵌入派生值来实现，客户端可以据此验证握手是否使用了加密的内部版本。
服务器还需要处理 GREASE ECH 的情况。GREASE 是 IETF 引入的一种机制，用于防止网络 ossification（协议僵化）。当客户端不支持真正的 ECH 但希望避免暴露其能力时，它会发送一个 GREASE 扩展 —— 一个形式正确但内容随机的虚拟 ECH 请求。服务器在检测到 GREASE 时应忽略该扩展并继续传统握手，同时自身也可以发送 GREASE 配置以测试网络兼容性。
安全属性与攻击缓解
ECH 的设计针对多种主动和被动攻击提供了缓解措施。对于被动观察者而言，由于 SNI 被加密，连接的目标服务器身份得到保护。但需要明确的是，ECH 本身并不足以完全隐藏服务器身份 —— 如果 DNS 查询未加密，攻击者仍可通过监控 DNS 流量获取目标域名；此外，服务器的 IP 地址本身也是潜在的标识符。因此，ECH 通常与加密 DNS（如 DoH 或 DoT）配合使用，以实现完整的隐私保护。
针对主动攻击，ECH 防范了若干危险场景。客户端反应攻击（Client Reaction Attack）通过观察客户端对错误证书的处理来推断 SNI 值，ECH 通过确保 ClientHelloInner.random 不被攻击者获知来抵御此类攻击。HelloRetryRequest 劫持攻击则利用服务器的握手状态管理尝试泄露信息，ECH 通过在两次 ClientHello 中重用相同的 HPKE 上下文来防止这种情况。客户端消息可塑性攻击（ClientHello Malleability Attack）试图通过修改外部消息来探查内部信息，ECH 通过对整个 ClientHelloOuter 进行认证来阻止这一攻击。
在拒绝服务方面，服务器需要警惕 trial decryption 攻击 —— 攻击者发送大量无法解密的 ClientHello 消息以消耗服务器计算资源。服务器可以通过速率限制和配置标识符验证来缓解此类攻击。此外，RFC 9849 要求服务器实现线性时间的外部扩展处理，以防止构造恶意扩展列表导致处理时间爆炸。
工程部署考量
在实际部署中，ECH 面临若干挑战。首先是中间件兼容性，虽然 TLS 扩展在标准上应被中间件忽略，但许多现实网络设备会对 ClientHello 进行深度检测，可能干扰 ECH 扩展的传递。服务器运营商应在启用 ECH 前确保所有端点理解相关配置，并保留旧密钥的支持以处理缓存的客户端配置。其次是回退机制的安全性，客户端在 ECH 被拒绝后必须确保不向明文连接泄露敏感信息，并验证服务器证书是否对公共名称有效。
部署模式选择也需要仔细考量。在共享模式（Shared Mode）中，服务器同时充当客户端面向服务器和后端服务器，适合单一提供商托管多个域名的场景；在分离模式中，客户端面向服务器可以是无密钥的代理，仅转发流量给后端服务器，适合需要严格密钥分离的部署。匿名集合的大小直接影响隐私保护强度 —— 使用相同 ECH 配置的服务器越多，观察者越难以区分不同的目标域名。
总结
RFC 9849 定义的 ECH 机制为 TLS 协议提供了重要的隐私增强能力，通过在握手阶段加密 SNI 和其他敏感扩展，使得网络观察者无法从 ClientHello 中获取目标服务器信息。其工程实现涉及 ECH 配置管理、双层 ClientHello 构造、HPKE 加密解密流程、填充策略以及服务器回退处理等多个环节。尽管部署仍面临中间件兼容性和密钥分发等方面的挑战，但 ECH 已成为 TLS 隐私保护的关键技术方向，为构建更安全的互联网通信基础设施奠定了基础。
资料来源：RFC 9849（https://www.rfc-editor.org/rfc/rfc9849）