一项“填补我们现有在线安全基础设施中的隐私空白”的尖端技术，如果被广泛采用，“可能永远就解决隐私问题”。听起来很有前途吧？这就是 Mozilla 和 Cloudflare 对 Encrypted Client Hello（简称：ECH）的描述，该协议对整个 “hello” 信息或浏览器与网站服务器之间的首次通信进行加密。

我们认为，ECH 确实是互联网隐私的一个重要因素，Mozilla、Chrome 和 Cloudflare 等主要“互联网竞技者”对其支持的重要性不容低估。在 AdGuard，我们在 Windows、Mac 和 Android 应用程序中添加了对 ECH 的支持，因为我们相信该技术具有使浏览更加“私密”的潜力。AdGuard 的 ECH 支持适用于 AdGuard 过滤的所有应用程序和浏览器。但是，ECH 是否是解决隐私问题和彻底击败审查制度的一块缺失的拼图呢？尽管我们希望如此，但个可能性比较低。

在给大家泼冷水之前，我们需要退后一步，先了解一些基本知识，然后再对 ECH 及其对审查员、版权机构、偷窥者和其他窥探者的所谓无敌状态进行分析。

什么是 ECH？为什么我们需要它？

假设，有用户要给其朋友寄一封信。信封封好后，写上朋友的姓名和地址，然后只要不破坏信封，就任何人都无法打开信封阅读内容。但任何人都可以查看地址，而且还会知道你要把信寄给谁。

这就是 HTTPS 的工作原理，即（一种默认协议，超过 84% 的网站都在使用它）。在与网站建立加密连接时，浏览器传递的第一条信息被称为“Client Hello”。Client Hello 中的某些信息，如 SNI（服务器名称指示，是浏览器告诉服务器它要连接到哪个网站的一种方式），是不加密的。这就意味着网络运营商，包括 ISP，可以查看这个信息。服务器在收到 Client Hello 信息后，会回复一些称为 “Server Hello” 的信息，以完成与设备的"交接"流程。

来源：Cloudflare

打完第一声“招呼”后，浏览器与服务器交换的数据就会加密，只有用户和网站才能看到其中的内容。但此时，你的网络提供商已经知道你访问的网站名称。例如，如果用户访问 www.google.com，网络提供商无法看到搜索记录，但可以看到用户就在使用 Google。

以上描述的就是 TLS 握手的工作原理。TLS 是传输层安全（英文：Transport Layer Security）的缩写，这是一种加密协议，为通过互联网发送的数据提供端到端的安全。说得更专业一点，浏览器以明文形式向网站服务器发送的第一条 “Client Hello” 信息不仅包含 SNI，还包含 TLS 版本和加密算法。但最重要的是，发送的第一个数据包没有加密，因此任何可以看到网络流量的人都可以看到浏览器请求的网站名称。

主要问题在于，我们怎样才能保护第一份未加密的、暴露我们浏览活动的数据包？

这就是 Encrypted Client Hello 协议的作用所在。简单地说，ECH 就是对包含 SNI 的 Client Hello 信息进行加密，如前所述，SNI 是指用户正在访问的网站的名称。浏览器不会向任何第三方泄漏网站的真实域名（如 www.google.com），而只会显示所谓的面向客户服务器（英文：client-facing server）的名称，在该服务器后面隐藏着多个拥有自己域名的后端服务器。面向客户的服务器有一个通用域名：例如，Cloudflare 使用 cloudflare-ech.com 作为其面向客户的服务器名称。但是，浏览器如何知道向它发送哪些信息才能连接到特定网站呢？

Client-facing server 就像一个中间人，有一个特殊的解密密钥，可以打开你发的内信，看到网站名称。然后，它将请求转发到真正的域名，并发回响应。之所以能做到这一点，是因为 ECH 将 Client Hello 分成两部分：外部部分包含非敏感信息，如 client-facing server 的名称；内部部分包含内部 SNI，表示后端服务器的域名，也就是用户要访问的网站。继续以信件做比喻：这就好比在写给不同收件人的信上写相同的地址，而要想看到带有实际地址的内层信件，则必须破坏信封。

来源：Cloudflare

采用 ECH 的情况如何？

近几个月来，越来越多的业内人士开始热衷于 ECH。Google 开始在 Chrome 浏览器 117 中提供该功能，而 Chrome 浏览器 118 成为支持 ECH 的 Google 浏览器的第一个稳定版本。在 Firefox 中，ECH 在 Firefox 118 中默认开启，但只有在启用 DNS-over-HTTPS 后才能正常运作。Edge 也在 测试 ECH，但尚未推出稳定版本。

不过，浏览器对 ECH 的支持如果得不到服务器方面的回应，就没有什么意义。浏览器的支持只意味着浏览器可以向支持该协议的服务器发送加密的 ECH 信息。因此，市场上最受欢迎的 CDN 提供商 Cloudflare 也支持该协议的举措对 ECH 的采用产生巨大的影响。Cloudflare 处理互联网上大约 20% 的流量，宣布从 9 月底开始为所有免费计划的客户提供 ECH 支持，并鼓励付费客户申请该功能。

不过，该协议要被广泛接受和采用还有很长的路要走。目前，Cloudflare 的许多免费域名的 DNS 记录中都缺少有关 ECH 的信息，因此 Chrome 浏览器无法在这些网站上使用 ECH。不过，由于 ECH 的推广仍处于早期阶段，随着时间的推移，这个问题很可能即将得到解决。

那么隐私问题解决好了吗？

尽管我们希望尽早实现这个梦想，但似乎目前还只是我们的一厢情愿罢了。

一方面，如果 ECH 得到普遍采用，它将使世界各地互联网管理机构为打击网络盗版、实施地理围栏和审查而采用的一些久经考验的封堵技术失去作用。首先，执法当局将更难根据网站名称锁定特定网站，因为这些网站将被 ECH 隐藏。

不过，这并不意味着审查员无法克服这一障碍。他们可能需要做出一些调整，但仍有可能进行屏蔽。

ECH 缺点或潜在的拦截方式

现在，我们要扮演魔鬼代言人的角色，给大家介绍一些具体的方法，让审查人员能够在实施 ECH 的情况下，仍然能够试图封锁网站。

• 一种方法是将 ECH 从 DNS 记录中"剪切"。要与服务器建立 ECH 连接，浏览器需要该服务器的特殊 DNS 记录。该记录会告诉浏览器在 ECH 的外部和内部使用哪个域名和解密密钥。但是，如果用户的 DNS 流量没有加密（大多数用户都是这种情况），那么任何可以查看 DNS 查询的他人，如 ISP 或审查员，也可以看到 ECH 记录。他们可以使用记录识别并阻止用户的 ECH 连接。当然，如果用户对 DNS 流量进行加密，那么这种方法就不起作用了。

• 一个更简单但相当有效的方法是屏蔽所有已知的 client-facing servers，如 clouflare-ech.com。实际上，这些服务器的数量应该不多，因此审查员不难识别并阻止所有服务器。但这种方法风险很大，因为它可能会破坏许多用户的互联网。如果审查员屏蔽所有支持 ECH 的服务器，那么浏览器就无法与启用 ECH 的网站建立连接。这反过来又会促使 Cloudflare 在互联网审查严格的国家禁用 ECH。如果 client-facing servers 被中国或俄罗斯等国的审查机构封锁，Cloudflare 将如何应对，我们拭目以待。可以确定的是，他们将面临一个艰难的选择。还有一个隐患等待着那些寄希望于 ECH 作为所有隐私相关问题的最终解决方案的人，那就是网站所有者可能会拒绝采用它，或者因为同样的原因而选择退出该协议。如果审查人员将 ECH 作为目标，使启用 ECH 的网站无法访问，那么网站所有者可能会选择关闭对 ECH 的支持，而不是失去他们的访问者。

不可否认，ECH 是一项令人兴奋且前景广阔的技术，旨在让互联网更加私密。然而，ECH 并非万无一失，也不应被视为抵御监视与跟踪的“灵丹妙药”。此外，该技术的广泛应用有利于使用某些 CDN 服务，如 Cloudflare 提供的服务。虽然这些服务本身可能没有问题，但作为采用 ECH 的副作用，它们的推广有可能使互联网比以前更加集中化。这究竟是好是坏，只有时间才能解答。