# 加密的 Client Hello 和 DoH：外围防火墙无法再看到什么

> ECH (RFC 9849) 在 TLS 握手中隐藏真实主机名，DoH 隐藏 DNS 查找。这会从网络防火墙中删除什么、不删除什么以及可见性会发生变化。

HisnLabs Security & Research Team · Published 2026-09-25
Canonical: https://hisnlabs.com/zh/blog/encrypted-client-hello-ech-doh-blind-perimeter-firewalls

二十年来，网络防火墙和代理一直依靠一个未加密的字段来了解加密流量的去向：服务器名称指示 (SNI)，即客户端在 TLS 握手的第一条消息中宣布的主机名。 HTTPS 上的 DNS（DoH、[RFC 8484](https://www.rfc-editor.org/rfc/rfc8484.html)）已经隐藏了连接之前的 DNS 查找。加密的 Client Hello，现在发布为[RFC 9849](https://www.rfc-editor.org/rfc/rfc9849.html)，隐藏了 SNI 本身。它们一起消除了大多数出口过滤所依赖的两个信号。

## ECH 的工作原理：内部和外部 ClientHello

使用 ECH，客户端构建两个 ClientHello 消息。内层携带真实目的地和敏感参数，并使用HPKE加密为服务器预先发布的公钥。外部以明文形式发送，带有共享的公共名称，通常是提供商前端的名称，因此观察者只能得知客户端正在与该提供商交谈（[RFC 9849](https://www.rfc-editor.org/rfc/rfc9849.html)；[Cloudflare 的解释器](https://blog.cloudflare.com/encrypted-client-hello/)）。

*网络观察者所看到的（说明性）*

```text
TLS ClientHello (outer, cleartext)
  server_name:            cloudflare-ech.com      <- shared public name
  encrypted_client_hello: <HPKE ciphertext>        <- real hostname is inside

```

## 密钥来自哪里：HTTPS DNS 记录

客户端在握手之前需要服务器的 ECH 公钥。它从 HTTPS 资源记录（类型 65，[RFC 9460](https://www.rfc-editor.org/rfc/rfc9460.html)）中的 DNS 获取，其 `ech` 参数携带 ECHConfigList。我们询问了一个真实的。 macOS 附带的 `dig` 不知道该记录的名称，因此请按编号询问：

*终端，macOS 26.7，2026 年 9 月 25 日*

```console
$ dig crypto.cloudflare.com TYPE65 +short
\# 133 0001000001000302683200040008A29F874FA29F884F000500470045 FE0D0041AF…
     …0012636C6F7564666C6172652D6563682E636F6D
# 0005 = the "ech" key, FE0D = ECH config version, and the last bytes decode to
# the ASCII public name: cloudflare-ech.com
```

如果该 DNS 查询本身通过 DoH 传输，则网络观察者既看不到查找，也看不到握手中的主机名（使用 ECH）。这就是本文要讨论的组合。

## 是否使用ECH取决于客户端

ECH 不是网络启动的东西；每个客户都决定。浏览器已提供支持 ([Chrome 平台状态](https://chromestatus.com/feature/6196703843581952))，通常与正在使用的加密 DNS 相关。很多软件根本不使用它。 Cloudflare 的跟踪端点报告它收到的内容，并且 macOS 内置的 `curl` 仍然以明文形式发送主机名：

```console
$ curl -s https://crypto.cloudflare.com/cdn-cgi/trace | grep -E "^(tls|sni)="
tls=TLSv1.3
sni=plaintext
```

因此，今天的现实情况是一个混合体：浏览器越来越多地隐藏主机名，而许多其他程序则不会，并且为逃避监控而编写的软件可以选择故意使用 ECH 和 DoH。

## 外围防火墙丢失了什么，保留了什么

| 信号 | 普通 TLS + DNS | 欧洲卫生局 + 卫生部 |
| --- | --- | --- |
| DNS 查找（哪个名称） | 在端口 53 上可见 | 隐藏在 HTTPS 内部到解析器 |
| SNI（主机名） | 可见的 | 仅共享公开名称 |
| 目的IP和端口 | 可见的 | 仍然可见 |
| 局域网内有哪些设备 | 可见的 | 仍然可见 |
| 设备上的哪个程序 | 不可见 | 不可见 |

*在共享提供商前端，目标 IP 通常标识提供商，而不是站点。*

诚实的总结是，边缘基于主机名的过滤不再对 ECH 流量起作用，而基于 IP 的控制则不会。网络仍然可以拒绝与已知的 DoH 解析器的连接，这实际上也阻止浏览器通过加密的 DNS 获取 ECH 密钥，并且它仍然可以阻止地址范围。它无法再区分同一提供商背后的两个站点，或者允许一个站点并阻止另一个站点，而不会以 ECH 设计检测的方式破坏 TLS。

> **Warning:** 声称 ECH 使流量“无法追踪”或边界过滤“过时”的说法太过分了：IP、时间、流量和设备仍然可见。丢失的是主机名，以及随之而来的最简单的策略杠杆。

## 可见性移动到端点

主机名永远不会隐藏的地方是建立连接的机器：程序通过名称请求它。这就是 ECH 将出口控制转向端点的原因。基于主机的防火墙根本不需要读取握手；它会在任何加密字节离开之前查看哪个进程打开了连接、连接到哪个地址，以及程序何时解析名称、哪个名称。它还可以看到网络设备甚至在 ECH 之前也无法看到的一件事：机器上的哪个应用程序正在通话。

- 根据应用程序而不是主机名来决定：浏览器、同步客户端和未知的二进制文件有不同的规则。
- 将启动自己的 DoH 到系统未配置的解析器的程序视为值得一看的信号。
- 将基于 IP 的阻止列表保持在边缘；它们仍然有效，而且不需要任何成本。

## FireAI 和 HisnLabs 在其中扮演的角色

ECH hides the hostname from the network, not from the machine making the connection: an on-device firewall such as FireAI still sees which process is connecting and where, and asks before an app it does not know goes online.

FireAI 是 HisnLabs 自己的产品：一款直接在 Mac 上运行的 AI 防火墙。它用通俗易懂的语言显示你的应用建立的每一个连接，并让你决定哪些数据可以离开你的 Mac——它的 AI 在本地运行，因此你的流量永远不会发送给我们或任何其他人。HisnLabs 的安全研究团队负责让这些判断保持准确：归类哪些域名只是普通的遥测、哪些属于真正的服务，追踪连接背后的国家和网络，并用真实的流量模式训练设备端模型（FireAI Pilot 功能）——这一切都不会离开你的 Mac。

你可以阅读它背后的技术决策，或试用 FireAI 17 天：[HisnLabs 出品的 FireAI](https://hisnlabs.com/fireai/zh/download)。

## Sources

- [RFC 9849: TLS Encrypted Client Hello](https://www.rfc-editor.org/rfc/rfc9849.html)
- [RFC 9460: SVCB and HTTPS DNS resource records](https://www.rfc-editor.org/rfc/rfc9460.html)
- [RFC 8484: DNS Queries over HTTPS (DoH)](https://www.rfc-editor.org/rfc/rfc8484.html)
- [Cloudflare: Good-bye ESNI, hello ECH!](https://blog.cloudflare.com/encrypted-client-hello/)
- [Chrome Platform Status: Encrypted Client Hello](https://chromestatus.com/feature/6196703843581952)