RFC 9849提出了一种TLS协议新机制，通过服务器公钥加密ClientHello消息，增强TLS握手过程中的隐私保护。该标准由IETF制定，于2026年3月发布。

RFC 9849：TLS加密客户端问候（Encrypted Client Hello，简称ECH）

本文档描述了一种在传输层安全协议（TLS）中加密ClientHello消息的机制，该消息使用服务器公钥进行加密。以下是主要内容的中文概述：

1. 引言

• 背景：TLS 1.3虽然加密了大部分握手过程，但ClientHello中的服务器名称指示（SNI）扩展仍以明文传输，可能泄露目标域名。
• 目标：通过加密ClientHello保护SNI及其他敏感字段（如应用层协议协商ALPN列表），确保连接到同一服务提供商的多个服务器时，外部观察者无法区分具体连接的是哪个服务器。

2. 关键机制

• ECH配置：服务器发布包含公钥和元数据的ECH配置，客户端使用此配置加密ClientHello。
  • ClientHelloInner：真实的客户端问候消息，包含敏感信息（如真实SNI）。
  • ClientHelloOuter：外层的客户端问候消息，包含无害的扩展值和加密的ClientHelloInner。
• 服务器行为：
  • 若支持ECH并成功解密，则使用ClientHelloInner继续握手。
  • 若不支持或解密失败，则使用ClientHelloOuter，但连接不可用于应用数据，客户端需根据服务器返回的更新配置重试。

3. 部署模式

• 共享模式：服务提供商同时作为客户端面向服务器和后端服务器，直接终止TLS连接。
• 拆分模式：客户端面向服务器（如反向代理）将连接中继到后端服务器，后者终止TLS连接，确保前者无法访问加密部分以外的握手内容。

4. 安全与隐私

• 目标：
  1. 安全性保持：ECH不削弱TLS原有安全属性。
  2. 握手隐私：连接到匿名集中任一服务器的行为不可区分。
  3. 抗降级：攻击者无法将ECH连接降级为非加密连接。
• 威胁模型：针对被动和主动攻击者，要求客户端面向服务器与后端服务器之间的通道需认证，且攻击者无法关联两端消息。

5. 兼容性考虑

• 中间件兼容：需确保中间盒（如代理）能正确处理ECH扩展，避免因未知扩展而中断连接。
• 部署影响：依赖SNI的现有功能（如负载均衡）可能需调整以适应ECH。

6. IANA注册

• 新增TLS扩展类型encrypted_client_hello（0xfe0d）和ech_outer_extensions（0xfd00）。
• 新增TLS警报类型ech_required（121）。
• 创建“TLS ECHConfig扩展”注册表，用于管理ECH配置扩展类型。

7. 安全考量

• 密钥管理：服务器应定期轮换ECH密钥以减少长期暴露风险。
• 填充策略：推荐客户端对ClientHelloInner进行填充，防止长度泄露敏感信息。
• 主动攻击防御：通过绑定ClientHelloOuter与加密内容、限制解压缩逻辑复杂度等措施，抵御篡改和放大攻击。

8. 实施要求

• 默认HPKE加密套件：使用X25519密钥封装、HKDF-SHA256密钥派生和AES-128-GCM加密。

总结

ECH通过加密ClientHello增强了TLS握手的隐私性，尤其保护了SNI等敏感信息。其设计兼顾了兼容性和安全性，支持灵活部署模式，并提供了对抗常见攻击的机制。实际部署时需注意密钥管理、中间件兼容性及依赖SNI的功能适配。

以下是评论内容的总结：

1. 技术影响与实现问题

   • 有用户询问ECH是否会影响负载均衡器的工作方式（评论1："Will this have an impact on Loadbalancers?"）
   • 另一用户指出ECH可能导致浏览器缓存问题，尤其是在Cloudflare免费层无法关闭该功能时（评论3："it's causing us problems... sometimes it works, sometimes it doesn't"）

2. 隐私与审查规避

   • 用户提到ECH有助于绕过网络审查，如印度Jio的网站封锁（评论4："cloudflare adopted the ESNI draft... made their SNI based blocking easy to bypass"）
   • ECH允许客户端使用公共名称连接网站，绕过中间审查设备（评论4："clients can use public_name's that middleboxes approve"）

3. 技术规范与限制

   • 用户质疑规范中排除基于IP证书的合理性，认为这限制了小型服务器的使用（评论5："why are IP-based certificates explicitly ruled out?"）
   • 另一用户提到Caddy已支持ECH，并提供了技术细节链接（评论6："Caddy already supports ECH"）

4. 安全与检测影响

   • 用户指出ECH会破坏TLS指纹识别作为机器人检测信号的能力（评论7："ECH basically kills TLS fingerprinting as a bot detection signal"）
   • 对Cloudflare等既支持ECH又依赖TLS指纹的厂商提出疑问（评论7："seems like they're eating their own lunch"）

5. 替代方案调侃

   • 用户调侃称如果有技术能避免多服务器共享IP，ECH可能就不必要（评论8："If only we had some technology..."）

总结：评论围绕ECH的技术影响、隐私优势、规范限制及安全检测冲突展开，既有支持也有批评，同时包含实际应用中的问题。