Encrypted Client Hello（ECH）：TLS 握手隐私保护的新范式

密码学概念 · 2026-09-28

一、为什么需要 ECH？

1.1 SNI 隐私泄露问题

在 TLS 握手过程中，客户端必须在明文发送 Server Name Indication（SNI） 扩展，告诉服务器它想访问哪个域名。这一设计源于早期 TLS 对虚拟主机（Virtual Hosting）的支持需求。

然而，SNI 明文传输带来了严重的隐私问题：

威胁场景	攻击者能力	受影响用户规模
网络运营商（ISP）日志	记录所有 SNI	全国性
防火墙深度包检测（DPI）	实时阻断特定域名	国家级
公共 Wi-Fi 热点	嗅探用户访问记录	公共场所
中间人代理（透明代理）	解密并重定向流量	企业网络

根据 Mozilla 2022 年的一项研究，全球超过 70% 的 TLS 连接都会暴露 SNI 信息。这意味着用户在访问任何网站时，其浏览历史的关键部分（域名）都会被网络路径上的第三方感知。

1.2 现有方案的局限性

在 ECH 出现之前，社区尝试了多种方案：

方案一：DNS over HTTPS（DoH）

优点：保护 DNS 查询隐私
缺点：不保护 TLS 握手的 SNI；需要客户端显式配置

方案二：DNS over TLS（DoT）

优点：加密 DNS 查询
缺点：同样不保护 SNI；端口 853 常被防火墙阻断

方案三：代理服务器（Proxy）

优点：完全隐藏真实目标
缺点：破坏端到端连接；需要信任中间代理

方案四：TLS 1.3 加密 SNI 草案（draft-ietf-tls-sni-encryption）

优点：协议层原生支持
缺点：需要修改 TLS 协议本身；浏览器和服务器兼容性差

这些方案的共同缺陷是：要么需要客户端主动配置，要么无法在标准 TLS 握手流程中无缝集成。

二、ECH 的设计哲学

2.1 核心思想：混淆而非隐藏

ECH 的设计哲学与传统隐私方案不同。它不试图完全隐藏通信事实，而是让中间人只能看到加密后的 SNI，无法解析出具体域名。

CODE

传统 TLS：
客户端 ──SNI: www.example.com──► 服务器
                    │
                    ▼
              中间人看到明文域名

ECH TLS：
客户端 ──SNI: {encrypt(www.example.com)}──► 服务器
                    │
                    ▼
              中间人只能看到密文

2.2 三方角色模型

ECH 引入了三个参与方：

角色	职责	示例
客户端（Client）	发起 TLS 连接，使用 ECH 加密 SNI	浏览器、移动 App
代理服务器（Proxy）	解密 ECH 内容，转发到目标服务器	CDN 节点、负载均衡器
目标服务器（Origin）	最终处理请求，配置 ECH 公钥	网站后端

这种设计的精妙之处在于：代理服务器不需要知道用户访问的具体域名，只需根据加密后的 SNI 决定路由到哪个目标服务器。

2.3 与 HPKE 的结合

ECH 使用 Hybrid Public Key Encryption（HPKE） 作为加密原语。HPKE 是 RFC 9180 定义的标准密钥封装机制，具有以下特点：

支持身份基加密（Identity-Based Encryption）
提供认证加密（AEAD）
计算效率高，适合 TLS 握手场景

HPKE 的具体工作流程：

目标服务器生成 HPKE 密钥对（公钥公开，私钥私有）
客户端获取公钥（通过 OHTTP 或其他带外方式）
客户端使用公钥加密 SNI
代理服务器使用私钥解密 SNI

三、ECH 协议详解

3.1 TLS 扩展定义

ECH 在 TLS 1.3 中定义了新的扩展类型：

扩展名称	类型值	说明
`encrypted_client_hello`	0x0033	ECH 扩展标识
`outer_extensions`	0x0034	外部扩展（供代理服务器解析）

3.2 ClientHello 结构

ECH 的 ClientHello 消息结构如下：

struct {
    SelectVersionConfig select_version_config;
    EncryptedClientHelloConfigList config_list;
    EncryptedClientHello outer_hello;
} EncryptedClientHelloExtension;

struct {
    HpkePublicKey public_key;
   HpkeCiphertext ciphertext;
} EncryptedClientHello;

关键设计点：

select_version_config：客户端选择使用哪个 ECH 配置版本
config_list：可选的多个 ECH 配置列表
outer_hello：实际加密的 ClientHello 内容

3.3 握手流程

CODE

┌─────────┐        ┌─────────┐        ┌─────────┐
│  客户端  │        │  代理   │        │  服务器  │
└────┬────┘        └────┬────┘        └────┬────┘
     │                  │                  │
     │  ClientHello     │                  │
     │  + ECH extension │                  │
     │─────────────────►│                  │
     │                  │                  │
     │                  │  ServerHello     │
     │                  │  + ECH config    │
     │◄─────────────────│                  │
     │                  │                  │
     │                  │  Decrypt SNI     │
     │                  │  → 确定目标服务器│
     │                  │                  │
     │                  │  转发 ClientHello│
     │                  │  ──────────────► │
     │                  │                  │
     │                  │                  │  完成握手
     │◄─────────────────┼──────────────────│
     │                  │                  │

3.4 错误处理与回退

如果客户端或服务器不支持 ECH，协议会自动回退到标准 TLS 1.3 握手：

CODE

情况一：客户端不支持 ECH
→ 发送标准 ClientHello，不包含 ECH 扩展
→ 服务器正常响应，SNI 明文传输

情况二：服务器不支持 ECH
→ 客户端检测到服务器不支持 ECH
→ 自动回退到标准 TLS 握手

情况三：代理服务器无法解密
→ 返回 HTTP 503 错误
→ 客户端可重试不带 ECH 的连接

四、安全性分析

4.1 威胁模型

ECH 的设计假设：

可信服务器：目标服务器不会滥用 ECH 公钥
不可信代理：代理服务器可能泄露 ECH 信息
被动攻击者：网络路径上的观察者无法解密 ECH

4.2 安全保障

安全属性	保障措施	保障强度
SNI 保密性	HPKE 加密	强（需要私钥）
完整性	AEAD 认证	强（防篡改）
抗重放	随机 nonces	强
前向保密	临时密钥对	强

4.3 已知限制

服务器侧隐私泄露：目标服务器可以看到明文 SNI
握手延迟增加：额外的加密/解密操作增加约 1-2 RTT
证书匹配问题：服务器证书必须与解密的 SNI 匹配
中间件兼容性：某些防火墙/负载均衡器可能干扰 ECH

五、国密适配挑战

5.1 当前状态

目前 ECH 标准基于国际标准（HPKE），在国密生态中存在以下适配问题：

问题	影响	解决方案
HPKE 基于 NIST 曲线	国密环境不兼容	定义国密 HPKE 变体
SM2 密钥封装效率低	握手延迟增加	优化密钥封装算法
TLS 扩展类型分配	需要 IANA 分配	申请专用扩展类型

5.2 可能的国密适配路径

路径一：GM/T 0024-2023 扩展 在 SSL VPN 技术规范中增加 ECH 支持，定义国密版本的 ClientHello 结构。

路径二：SM2-HPKE 基于 SM2 椭圆曲线重新实现 HPKE 密钥封装，保持协议兼容。

路径三：SM2 直接加密 SNI 使用 SM2 加密算法直接加密 SNI，简化实现但牺牲前向保密性。

5.3 现实考量

当前阶段，ECH 的国密适配仍处于研究阶段。主要障碍包括：

国密 TLS 生态对 SNI 隐私的关注度较低
国密部署通常在内网环境中，SNI 泄露风险较小
HPKE 国密化的标准制定需要时间

六、工程实践建议

6.1 客户端部署

如果需要在客户端支持 ECH：

JAVASCRIPT

// 伪代码：使用 ECH 发起 TLS 连接
const config = await fetchECHConfig('example.com');
const encryptedHello = await encryptClientHello(
  config.publicKey,
  { sni: 'www.example.com' }
);

const tlsSocket = new TLSSocket({
  clientHello: encryptedHello,
  useECH: true
});

6.2 服务器端部署

服务器需要：

生成 HPKE 密钥对
发布 ECH 配置（可通过 OHTTP 或 DNS TXT 记录）
配置代理服务器支持 ECH 解密
确保证书与解密后的 SNI 匹配

6.3 代理服务器部署

代理服务器需要：

持有 ECH 私钥
支持 HPKE 解密
能够根据解密的 SNI 路由到正确的后端
不记录或泄露 ECH 内容

七、总结与展望

ECH 代表了 TLS 隐私保护的一个重要方向：在不改变现有互联网基础设施的前提下，通过协议扩展增强隐私保护。

7.1 核心价值

隐私增强：有效防止 SNI 嗅探
向后兼容：不支持 ECH 的系统仍可正常工作
标准化：基于 RFC 8475 和 RFC 9180

7.2 未来趋势

主流浏览器支持：Chrome、Firefox 已开始实验性支持
CDN 集成：Cloudflare、Akamai 等已部署 ECH
国密适配：未来可能在 GM/T 标准中定义国密版本

7.3 实践建议

对于当前的国密项目：

短期：关注 ECH 发展，评估未来适配成本
中期：在敏感场景（如跨境传输）中试点 ECH
长期：参与国密 ECH 标准制定

参考

← 返回知识库