近日Cloudflare在官方博客发表了“Encrypted Client Hello – 隐私的最后一块拼图”的文章，宣布正式开始支持Encrypted Client Hello(ECH)。
以下是博客的一些中文翻译段落：
今天，我们很高兴宣布为改善互联网上的个人隐私做出了贡献。Encrypted Client Hello(ECH)是一个新的提议标准，可以防止网络窥探用户正在访问哪些网站，现在已经在所有 Cloudflare 计划中提供。
Encrypted Client Hello是 ESNI 的继任者，它隐藏了 TLS 握手的服务器名称指示（SNI）。这意味着每当用户访问启用了 ECH 的 Cloudflare 上的网站时，除了用户、Cloudflare 和网站所有者之外，没有人能够知道用户访问了哪个网站。Cloudflare 是个人隐私的大力支持者，并对将这项技术付诸实践感到兴奋。
随着时间的推移，我们希望其他人会效仿我们，从而实现更加私密的互联网。提供 ECH 的供应商越多，就越难以监听用户在互联网上的活动。甚至，我们可能会永久解决隐私问题。
ECH如何保护隐私
要了解ECH如何保护隐私，首先要知道我们的数据是如何泄漏的。
在互联网早期，可用性优先级最高，安全和隐私方面考虑较少。直到本世纪初，CPU计算能力弱，加解密带来的性能损耗不容忽视，另外SSL证书昂贵，明文的HTTP、SMTP还是主流。在明文协议下，网络连接中的任何一个中间节点，都能将用户数据一览无余（甚至进行修改），包括用户名密码等敏感数据。为了解决这个问题，SSL和TLS（TLS是SSL的继任者，本文后续都用TLS）先后被提出来。通过引入TLS以及PKI体系，中间网络节点无法查看/篡改用户数据，互联网在隐私和安全性上迈出了一大步。
但仅有HTTPS还足以完全保障用户的隐私，用户和服务器之外的节点还有获取用户访问了什么网站的手段：一种是DNS，另一种则是TLS握手时发送的明文SNI。
DNS也是非常古老的协议，直到今天也是互联网的基石。DNS负责将用户访问的网址解析成具体的IP地址，由于其基于UDP协议且未加密的特性，现在仍被广泛恶意利用：UDP不需要建立双向连接，因此可以伪造来源数据包进行DNS反射攻击（DDoS流量攻击的一种）；网络中的任何一个节点都可以进行DNS抢答，在某些网络环境下会造成DNS污染（DNS投毒）。
DNS查询是明文的，因此DNS服务器可以轻易知道用户访问了什么网站（一些公司/集团的网关能知道员工访问的网站也就不足为奇了），这就带来了隐私泄漏。为了解决这个问题，DoT（DNS over TLS）和DoH（DNS over HTTPS）先后被提出来，目前看来是DoH胜出了，主流浏览器都（即将）支持DoH了。
有了DoH，网络浏览中最后的隐私担忧就是TLS握手时发送的明文SNI了。这里先解释一下为什么需要SNI（Server Name Indication）。
最初HTTPS是不需要SNI的，因为早期一个IP地址/服务器只放一个网站是很正常的。但是慢慢网站多了，一个IP地址/服务器上需要放多个加密网站并且共用443端口，用户请求的时候怎么知道访问哪个站呢？为了解决这个问题，2003年SNI作为TLS的拓展被加了进来。有了SNI，多个HTTPS网站也可以以虚拟主机（Virtual Host）的形式在同一个IP/服务器上托管了，使用过Apache httpd配置过虚拟主机的网友应该对虚拟主机的概念比较熟悉。
web服务器需要通过用户提供的SNI选择SSL证书，因此TLS握手时SNI必须先明文发送（在Client Hello消息中），协商得到加密密钥后数据才加密传输。因为SNI是明文发送，数据途经的任何一个节点都能知道用户在访问哪个网站（虽然看不到网址等具体信息）。
最初解决SNI明文的提案是ESNI，目前已经被ECH取代。其原理是将原来的Client Hello拆成两部分，外部消息中的SNI是共享的，内部消息中的SNI才是真实的。在Cloudflare的方案中，真实的SNI只有用户、CF和服务器知道，从而解决了SNI泄漏问题，这也就是为什么CF说这是隐私的最后一块拼图。
如果你的网站使用了CF中转并且是免费计划（白嫖用户），恭喜你，相当于服务端已经默认帮你开启了ECH支持了，用户端开启ECH就能用上最先进的ECH保护了。使用其它CDN或者web服务器的，可能需要等待相关软件支持了（毕竟Nginx才刚把http3/quic支持加上）。
ECH依赖一种新型的DNS记录，因此ECH是依赖于DoH的。在Firefox 118及以上版本浏览器中，启用DoH就会开启ECH，其中DoH提供商可以选择CF或者其他家。
Chrome 105及以上版本对ECH已经实验性支持，用户可设置下列flag开启：
chrome://flags/#dns-https-svcb chrome://flags/#encrypted-client-hello chrome://flags/#use-dns-https-svcb-alpn
SNI白名单
CF的这个举动让我想起了一个相关的词：SNI白名单。SNI白名单据说是某些地区，出于反诈或者其它目的，只允许访问备案或者白名单上的网站，其余网站一律阻断（其实本人在移动网络下也体验过类似的，第一次能正常打开外面的网站，再刷新就打不开了）。
ECH怎么就和SNI白名单扯上关系了？当然有关系：ECH是隐藏用户的SNI保护用户隐私，另外一个则是限制只能看哪些网站。而加深我对SNI白名单记忆的则是 Xray团队开发的 Reality协议。
鉴于简中互联网在技术防封锁方面遥遥领先，几个月不关注可能就跟不上最新的技术线路，这里根据自己的理解总结一下 @rprx 及Xray开发团队的代表性工作：
- 设计了无状态的轻量级数据传输协议 VLESS，号称“性能至上、可扩展性空前，目标是全场景终极协议”；VLESS协议解决了TLS时数据多次加密的问题，并且支持分流和回落；
- 提出了 划时代的革命性概念和技术：XTLS。XTLS复用了真实TLS的加密能力，使得代理几乎无需再对https流量进行数据加解密，只起到流量中转的作用，极大的提高了性能。随XTLS而来的是splice和direct流控模式，客户端和服务端工作量更少，更省电节能；
- 提出了XTLS vision流控模式，解决TLS in TLS的特征问题。TLS in TLS是基于TLS的V2ray、trojan等协议通病，XTLS vision的解决办法是填充TLS握手包到合理长度。中间rprx消失一段时间，该技术是 V2rayNG 的作者 @yuhan6665 提出；
- 提出了Reality协议，号称“THE NEXT FUTURE”。使用REALITY无需自己买域名、配置 TLS 服务端，但是要求目标网站支持TLS 1.3和H2，IP越接近越好(历史IP更佳)。Reality的这一行为最初也被称为“偷证书”，因此有Reality sni白名单的讨论（当然结论是dl.google.com这种目标网站不要用）。
Reality协议本质上其实就是使用看似正常的SNI从而绕过SNI白名单限制进行连接。Reality协议与服务端TLS握手时使用的自签证书，SNI用虚假的，连接建立后才使用用户访问网站的真实TLS。Reality可以搭配XTLS以外的代理协议使用，但是会存在TLS in TLS的特征，因此不建议。
可以看到Reality完全算得上是符合国情的技术创新，ESNI、DoH、DNSSEC这些技术无法直接用，才不得不夹缝中生存整出借白名单绕道的手段。至于ECH以后在特定地区能不能用，还真不好说。最极端的情况，把ECH共享的SNI全部封杀，ECH就完全没得玩了。
总结
其实ECH解决的仅仅是用户到服务器之间的隐私问题，实际中还有许多非常多的隐私泄漏情况：浏览器、输入法、操作系统等，甚至键盘等都可能收集数据上传，想要保护好隐私还真不是一件容易的事情。普通用户所能做的，就是尽量远离流氓软件，少用没有数据加密的软件或者硬件，毕竟随便去个小区都有可能让你登记身份证号、手机号，没人会在意你的隐私。