再见 ESNI，你好 ECH！—— ECH的前世今生

译者注：2024 年 9 月 25 日，Cloudflare 宣布再次推出 ECH 功能。借此契机，本人翻译了 Cloudflare 介绍 ECH 的博文 Good-bye ESNI, hello ECH!
，以便科普ECH的发展历程。

现代互联网上的大多数通信都经过加密，以确保其内容只有端点（即客户端和服务器）才能理解。然而，加密需要密钥，因此端点必须在不向潜在攻击者透露密钥的情况下就加密密钥达成一致。用于此任务（称为密钥交换）的最广泛使用的密码协议是传输层安全（TLS）握手。
在本文中，我们将深入探讨 ECH（Encrypted Client Hello，加密客户端问候），这是 TLS 的一个新扩展，有望显著增强这一关键互联网协议的隐私性。如今，TLS 连接的许多隐私敏感参数是在明文中协商的。这使得网络观察者可以获取大量元数据，包括端点的身份、它们如何使用连接等等。
ECH 对整个握手过程进行加密，从而使这些元数据保密。至关重要的是，这通过保护服务器名称指示（SNI）免受网络窃听者的攻击，填补了一个长期存在的隐私漏洞。加密 SNI 很重要，因为它是表明给定客户端正在与哪个服务器通信的最清晰信号。然而，也许更重要的是，ECH 还为在 TLS 中添加未来的安全特性和性能增强功能奠定了基础，同时将对最终用户隐私的影响降至最低。
ECH 是学术界和科技行业领导者密切合作的产物，由互联网工程任务组（IETF）促成，参与者包括 Cloudflare、我们在 Fastly 和 Mozilla 的朋友（他们都是该标准的共同作者的所属机构）以及许多其他机构。这一特性代表了对 TLS 协议的重大升级，它建立在前沿技术之上，比如仅现在才开始崭露头角的基于 HTTPS 的域名系统（DNS-over-HTTPS）。因此，该协议尚未准备好进行互联网规模的部署。本文旨在作为通往完全握手加密之路的一个路标。

背景

TLS 的故事就是互联网的故事。随着我们对互联网的依赖日益增加，该协议也在不断发展，以满足不断变化的操作要求、使用案例和威胁模型。客户端和服务器不仅仅是交换密钥。它们还协商各种各样的特性和参数：密钥交换的确切方法；加密算法；谁被认证以及如何认证；握手后使用哪个应用层协议；等等。所有这些参数都以某种方式影响通信通道的安全属性。
SNI 是影响通道安全的一个参数的主要例子。客户端使用 SNI 扩展来向服务器指示它想要访问的网站。这对现代互联网至关重要，因为如今许多源服务器位于单个 TLS 运营商之后是很常见的。在这种情况下，运营商使用 SNI 来确定谁将对连接进行认证：没有它，就无法知道要向客户端呈现哪个 TLS 证书。问题是 SNI 会将客户端想要连接的源服务器的身份泄露给网络，可能会让窃听者推断出关于他们通信的大量信息。（当然，网络观察者还有其他方法来识别源服务器 —— 例如源服务器的 IP 地址。但是与其他源服务器位于同一 IP 地址会使使用此指标确定源服务器比简单检查 SNI 要困难得多。）
虽然保护 SNI 是 ECH 的动力，但它绝不是客户端和服务器协商的唯一隐私敏感的握手参数。另一个是应用层协议协商（ALPN）扩展，它用于在 TLS 连接建立后决定使用哪个应用层协议。客户端发送它支持的应用程序列表 —— 无论是 HTTPS、电子邮件、即时通讯，还是使用 TLS 进行传输安全的无数其他应用程序 —— 服务器从该列表中选择一个，并将其选择发送给客户端。通过这样做，客户端和服务器向网络泄露了它们的能力以及连接可能用于何种用途的明确信号。
有些特性对隐私非常敏感，以至于它们在握手中的包含是不可行的。一个被提出的想法是用密码验证密钥交换（PAKE）取代 TLS 核心的密钥交换。这将允许基于密码的认证与基于证书的认证一起使用（或替代后者），使 TLS 更强大，适用于更广泛的应用。这里的隐私问题与 SNI 类似：服务器通常会为每个客户端关联一个唯一标识符（例如用户名或电子邮件地址），用于检索客户端的凭证；并且客户端必须在握手过程中以某种方式将此身份传达给服务器。如果在明文中发送，那么任何网络观察者都可以轻易获取这些个人身份信息。
解决所有这些隐私泄露问题的一个必要因素是握手加密，即除了应用数据之外，对握手消息进行加密。听起来很简单，但这个解决方案带来了另一个问题：如果握手本身就是一种交换密钥的方式，那么客户端和服务器如何选择加密密钥呢？当然，有些参数必须在明文中发送，所以 ECH 的目标是对除了完成密钥交换所必需的参数之外的所有握手参数进行加密。
为了理解 ECH 以及支撑它的设计决策，了解一下 TLS 中握手加密的历史会有所帮助。

TLS 中的握手加密

在最新版本 TLS 1.3 之前，TLS 根本没有握手加密。2013 年斯诺登事件曝光后，IETF 社区开始考虑应对大规模监控对开放互联网构成的威胁的方法。当 2014 年开始对 TLS 1.3 进行标准化时，其设计目标之一是尽可能多地对握手进行加密。不幸的是，最终标准没有实现完全握手加密，包括 SNI 在内的几个参数仍然在明文中发送。让我们仔细看看原因。
TLS 1.3 协议流程如图 1 所示。一旦客户端和服务器计算出一个新的共享密钥，握手加密就开始了。为此，客户端在其客户端问候（ClientHello）消息中发送一个密钥份额，服务器在其服务器问候（ServerHello）消息中用自己的密钥份额进行响应。交换这些份额后，客户端和服务器可以推导出一个共享密钥。随后的每个握手消息都使用从共享密钥派生的握手流量密钥进行加密。
应用数据使用一个不同的密钥进行加密，称为应用流量密钥，它也是从共享密钥派生的。这些派生的密钥具有不同的安全属性：为了强调这一点，它们用不同的颜色表示。
第一个被加密的握手消息是服务器的加密扩展（EncryptedExtensions）。此消息的目的是保护服务器的敏感握手参数，包括服务器的 ALPN 扩展，其中包含从客户端的 ALPN 列表中选择的应用程序。密钥交换参数在客户端问候和服务器问候中未加密发送。

客户端的所有握手参数，无论敏感与否，都在客户端问候中发送。查看图 1，你可能会想到一些重新设计握手的方法，以便对其中一些参数进行加密，也许会以增加延迟为代价（即，在网络上进行更多的往返）。然而，像 SNI 这样的扩展产生了一种 “先有鸡还是先有蛋” 的问题。
客户端在验证服务器的身份（这是证书（Certificate）和证书验证（CertificateVerify）消息的任务）并且服务器确认它知道共享密钥（这是完成（Finished）消息的任务）之前不会加密任何内容。这些措施确保了密钥交换是经过认证的，从而防止了中间人（MITM）攻击，在这种攻击中，攻击者以一种允许其解密客户端发送的消息的方式冒充服务器向客户端发送消息。因为服务器需要 SNI 来选择证书，所以它需要在密钥交换被认证之前传输。
一般来说，只有当客户端和服务器已经共享一个加密密钥时，才能确保用于认证的握手参数的保密性。但是这个密钥可能来自哪里呢？

TLS 1.3 早期的完全握手加密

有趣的是，完全握手加密曾经被提议作为 TLS 1.3 的一个核心特性。在协议的早期版本（大约 2015 年的草案 - 10）中，服务器会在握手期间向客户端提供一个长期有效的公钥，客户端会在后续的握手中使用该公钥进行加密。（这种设计来自一个名为 OP - TLS 的协议，而该协议又借鉴了原始的 QUIC 提案。）这种模式被称为 “0 - RTT”，其主要目的是允许客户端在完成握手之前开始发送应用数据。此外，它还允许客户端对客户端问候之后的第一组握手消息进行加密，包括它自己的加密扩展，这可能被用于保护客户端的敏感握手参数。
最终，这个特性没有被纳入最终标准（2018 年发布的 RFC 8446），主要是因为它的复杂性超过了它的实用性。特别是，它对保护客户端学习服务器公钥的初始握手没有任何作用。初始握手的服务器认证所需的参数，如 SNI，仍然会在明文中传输。
然而，这个方案作为其他握手加密机制（如 ECH）的先驱是值得注意的，这些机制使用公钥加密来保护敏感的客户端问候参数。这些机制必须解决的主要问题是密钥分发。

在 ECH 之前有（并且仍然有！）ESNI

ECH 的直接前身是加密 SNI（ESNI）扩展。顾名思义，ESNI 的目标是提供 SNI 的保密性。为此，客户端会使用服务器的公钥对其 SNI 扩展进行加密，并将密文发送给服务器。服务器会尝试使用与其公钥对应的私钥对密文进行解密。如果解密成功，那么服务器会使用解密后的 SNI 继续进行连接。否则，它会直接终止握手。这个简单协议的流程如图 2 所示。

对于密钥分发，ESNI 依赖于另一个关键协议：域名系统（DNS）。为了使用 ESNI 连接到一个网站，客户端会在其标准的 A/AAAA 查询中附带一个对包含 ESNI 公钥的 TXT 记录的请求。例如，要获取 crypto.dance 的密钥，客户端会请求_esni.crypto.dance 的 TXT 记录：

$ dig _esni.crypto.dance TXT +short "/wGuNThxACQAHQAgXzyda0XSJRQWzDG7lk/r01r1ZQy+MdNxKg/mAqSnt0EAAhMBAQQAAAAAX67XsAAAAABftsCwAAA="

这个 base64 编码的二进制大对象包含一个 ESNI 公钥以及相关参数，如加密算法。
但是，如果我们只是通过明文 DNS 查询将服务器名称泄露给网络观察者，那么加密 SNI 又有什么意义呢？随着基于 HTTPS 的域名系统（DNS-over-HTTPS，DoH）的引入，以这种方式部署 ESNI 变得可行，DoH 能够对提供 DoH 服务的解析器的 DNS 查询进行加密（1.1.1.1 就是这样一个服务的例子）。DoH 的另一个关键特性是它提供了一个经过认证的通道，用于将 ESNI 公钥从 DoH 服务器传输到客户端。这防止了源自客户端本地网络的缓存中毒攻击：在没有 DoH 的情况下，本地攻击者可以通过返回一个空的 TXT 记录阻止客户端提供 ESNI 扩展，或者强迫客户端使用它控制的密钥来使用 ESNI。
虽然 ESNI 向前迈出了重要的一步，但它没有达到我们实现完全握手加密的目标。除了不完整 —— 它只保护 SNI—— 它还容易受到一些复杂攻击，虽然这些攻击很难实施，但指出了协议设计中的理论弱点，需要加以解决。
2018 年，Cloudflare 部署了 ESNI，Firefox 也在可选的基础上启用了它，这一经历暴露了依赖 DNS 进行密钥分发的一些挑战。Cloudflare 每小时变更其 ESNI 密钥，以在密钥万一被泄露的情况下将附带损害降至最低。DNS 记录有时会被缓存很长时间，结果是客户端有很大可能拥有一个过时的公钥。虽然 Cloudflare 的 ESNI 服务在一定程度上容忍这种情况，但每个密钥最终都必须过期。ESNI 协议留下的问题是，如果解密失败并且客户端无法通过 DNS 或其他方式获取当前公钥，它应该如何继续。
另一个依赖 DNS 进行密钥分发的问题是，几个端点可能对同一个源服务器具有权威性，但具有不同的能力。例如，对 “example.com” 的 A 记录的请求可能会返回两个不同的 IP 地址之一，每个地址由不同的内容分发网络（CDN）运营。“_esni.example.com” 的 TXT 记录将包含其中一个 CDN 的公钥，但肯定不是两个。DNS 协议没有提供一种将对应于同一个端点的资源记录原子地绑定在一起的方法。特别是，客户端可能会不小心将 ESNI 扩展提供给一个不支持它的端点，导致握手失败。解决这个问题需要对 DNS 协议进行修改。（更多内容如下。）

**ESNI 的未来。**在下一节中，我们将描述 ECH 规范以及它如何解决 ESNI 的缺点。尽管有其局限性，然而，ESNI 提供的实际隐私益处是显著的。Cloudflare 打算继续支持 ESNI，直到 ECH 可以用于生产环境。

ECH 的细节

ECH 的目标是对整个客户端问候进行加密，从而通过保护所有隐私敏感的握手参数来填补 TLS 1.3 和 ESNI 留下的空白。与 ESNI 类似，该协议在客户端的第一次传输中使用一个通过 DNS 分发并使用 DoH 获取的公钥进行加密。但是 ECH 在密钥分发方面有改进，使协议对 DNS 缓存不一致更具鲁棒性。如果解密失败，ESNI 服务器会终止连接，而 ECH 服务器会尝试完成握手并向客户端提供一个它可以用来重试连接的公钥。
但是如果服务器无法解密客户端问候，它如何完成握手呢？如图 3 所示，ECH 协议实际上涉及两个 ClientHello 消息：ClientHelloOuter，像往常一样在明文中发送；以及 ClientHelloInner，它是加密的，并作为 ClientHelloOuter 的一个扩展发送。服务器只用其中一个 ClientHello 完成握手：如果解密成功，它会继续使用 ClientHelloInner；否则，它会继续使用 ClientHelloOuter。

ClientHelloInner 由客户端想要用于连接的握手参数组成。这包括敏感值，如它想要访问的源服务器的 SNI（在 ECH 术语中称为后端服务器）、ALPN 列表等等。ClientHelloOuter 虽然也是一个完整的 ClientHello 消息，但不用于预期的连接。相反，握手由 ECH 服务提供商本身完成（在 ECH 术语中称为面向客户端的服务器），向客户端表明由于解密失败无法到达其预期目的地。在这种情况下，服务提供商还会发送正确的 ECH 公钥，客户端可以用它重试握手，从而 “纠正” 客户端的配置。（这个机制类似于 TLS 1.3 早期服务器为 0 - RTT 模式分发其公钥的方式。）
至少，两个 ClientHellos 都必须包含服务器认证的密钥交换所需的握手参数。特别是，虽然 ClientHelloInner 包含真实的 SNI，但 ClientHelloOuter 也包含一个 SNI 值，客户端在 ECH 解密失败的情况下期望验证这个值（即面向客户端的服务器）。如果使用 ClientHelloOuter 建立连接，那么客户端应该立即终止连接并使用服务器提供的公钥重试握手。客户端在 ClientHelloOuter 中不需要指定 ALPN 列表，也不需要任何其他用于指导握手后行为的扩展。所有这些参数都被加密的 ClientHelloInner 封装。
这种设计相当巧妙地解决了早期机制在安全部署握手加密时遇到的大多数挑战。重要的是，ECH 的设计不是凭空构想出来的。该协议反映了 IETF 社区的不同观点，其发展与对 ECH 成功至关重要的其他 IETF 标准相契合。
第一个是一个重要的新 DNS 特性，称为 HTTPS 资源记录类型。从高层次上讲，这种记录类型旨在允许对同一个域名具有权威性的多个 HTTPS 端点宣传不同的 TLS 能力。这使得可以依赖 DNS 进行密钥分发，解决了最初 ESNI 部署所揭示的一个部署挑战。要深入了解这个新记录类型以及它对互联网更广泛的意义，请查看 Alessandro Ghedini 最近关于用 DNS 加速 HTTPS 的博客文章。
第二个是互联网研究任务组密码学研究小组（CFRG）的混合公钥加密（HPKE）标准，它指定了一个可扩展的框架，用于构建适用于各种应用的公钥加密方案。特别是，ECH 将其握手加密机制的所有细节委托给 HPKE，从而得到一个更简单、更易于分析的规范。（顺便说一下，HPKE 也是无感知基于 HTTPS 的 DNS 的主要成分之一。）

前方的道路

当前的 ECH 规范是多年合作的成果。在这一点上，协议的整体设计相当稳定。事实上，规范的下一个草案将是第一个针对实现之间的互操作性测试的草案。然而，仍然有一些细节需要解决。让我们用前方道路的简要概述来结束这篇文章。

抗流量分析

最终，ECH 的目标是确保连接到同一个 ECH 服务提供商后面的不同源服务器的 TLS 连接彼此无法区分。换句话说，当你连接到比如说 Cloudflare 后面的一个源服务器时，在你和 Cloudflare 之间的网络上没有人应该能够辨别你到达了哪个源服务器，或者你和源服务器协商了哪些隐私敏感的握手参数。除了立即提升隐私之外，如果实现这个特性，将为 TLS 部署新特性铺平道路，同时不损害隐私。
加密 ClientHello 是实现这个目标的重要一步，但我们还需要做更多的工作。我们还没有讨论的一个重要攻击向量是流量分析。这指的是对通信通道的属性进行收集和分析，这些属性会泄露部分密文的内容，但不会破解底层的加密方案。例如，加密 ClientHello 的长度可能会泄露足够关于 SNI 的信息，让对手能够对其值做出有根据的猜测（对于特别短或特别长的域名，这种风险尤其高）。因此，确保每个密文的长度与隐私敏感参数的值无关是至关重要的。当前的 ECH 规范提供了一些缓解措施，但它们的覆盖范围不完整。因此，提高 ECH 对流量分析的抵抗力是未来工作的一个重要方向。

僵化的幽灵

ECH 的一个重要未决问题是它对网络操作的影响。
从 TLS 1.3 的部署中吸取的一个教训是，升级一个核心互联网协议可能会引发意想不到的网络行为。Cloudflare 是最早大规模部署 TLS 1.3 的主要 TLS 运营商之一；当像 Firefox 和 Chrome 这样的浏览器开始在实验基础上启用它时，他们观察到与 TLS 1.2 相比，连接失败率显著更高。这些失败的根本原因是网络僵化，即中间盒（位于客户端和服务器之间的网络设备，用于监测和有时拦截流量）编写软件的倾向，这些软件期望流量看起来和表现出某种特定的方式。在中间盒有机会更新软件之前改变协议，导致中间盒试图解析它们不认识的数据包，触发软件错误，在某些情况下，导致连接完全中断。

这个问题非常普遍，以至于为了减轻网络僵化的影响，TLS 1.3 的设计被改变了。巧妙的解决方案是让 TLS 1.3 “看起来像” 另一个中间盒已知能容忍的协议。具体来说，数据包格式甚至握手消息的内容都被设计得类似于 TLS 1.2。这两个协议当然不完全相同 —— 一个好奇的网络观察者仍然可以区分它们 —— 但它们看起来和行为足够相似，以确保大多数现有的中间盒不会对它们区别对待。从经验上看，发现这种策略足以降低连接失败率，使 TLS 1.3 的部署可行。

再次，ECH 代表了对 TLS 的一次重大升级，网络僵化的幽灵笼罩着它。ClientHello 包含像 SNI 这样在握手中存在了很长时间的参数，我们还不知道加密它们会有什么影响。为了预期僵化可能导致的部署问题，ECH 协议被设计得尽可能像一个标准的 TLS 1.3 握手。最显著的差异是 ECH 扩展本身：如果中间盒忽略它 —— 如果它们符合 TLS 1.3 标准，它们应该忽略 —— 那么握手的其余部分将看起来和行为非常像往常一样。

ECH 是否足以确保其大规模部署还有待观察。如果是这样，值得注意的是这个新特性将有助于减轻未来 TLS 升级对网络操作的影响。加密整个握手减少了僵化的风险，因为这意味着软件可僵化的可见协议特征更少。我们相信这对互联网的整体健康是有益的。

结论

旧的 TLS 握手（无意地）存在漏洞。客户端和服务器的操作要求导致隐私敏感参数，如 SNI，完全在明文中协商并可供网络观察者获取。ECH 扩展旨在通过实现整个握手的加密来填补这个差距。这代表了对 TLS 的一次重大升级，随着协议的继续发展，它将有助于保护最终用户的隐私。

ECH 标准是一个正在进行的工作。随着这项工作的继续，Cloudflare 致力于尽自己的一份力量，确保对 TLS 的这一重要升级能够在互联网规模上进行部署。