一、先说Firefox如何设置ESNI
打开Firefox浏览器，
在地址栏输入 about:config 后回车，或者点工具栏上的“书签”→其他书签，点里面预设的 about:config
弹出安全警告：点“我了解此风险！”，会进入设置项
在搜索框中输入： network.security.esni.enabled
设为 true
二、检测ESNI是否生效
Cloudflare ESNI Checker | Cloudflare
https://www.cloudflare.com/ssl/encrypted-sni/
三、网络连接中的信息泄露/中间人攻击
1、TLS证书信息的暴露。这一问题在最新版的 TLS1.3 草案中得到了解决。Firefox 也已经支持了 TLS1.3 [5]。
2、DNS 查询会暴露你查询的域名。DNS 未经加密，有被中间人投毒的风险。这一问题的解决方案是加密 DNS 查询，目前有多种解决方案，DNSSEC，DNSCrypt，DoT，DoH。Firefox支持了其中的 DNS over HTTPS (DoH) [6]，并有很详细的科普[7]。
3、访问的 IP 地址会暴露。这个没有办法，封 IP 基本无解。
4、SNI 暴露域名信息。TLS 验证证书需要域名信息，而同一 IP 可能托管多个域名，所以就有了 SNI (Server Name Indication)。在建立 TLS 链接时 SNI 域名会明文发送，中间人就可以知道你访问了哪个域名，然后*河蟹*。ESNI 就是为了解决这个问题。
四、什么是Encrypted SNI（ESNI）
Secure DNS
Traditionally, DNS queries are sent in plaintext. Anyone listening on the Internet can see which websites you are connecting to.
To
ensure your DNS queries remain private, you should use a resolver that
supports secure DNS transport such as DNS over HTTPS (DoH) or DNS over
TLS (DoT).
The fast, free, privacy focused 1.1.1.1
resolver supports DNS over TLS (DoT), which you can configure by using a
client that supports it. For a list of these take a look here. DNS over HTTPS can be configured in Firefox today using these instructions. Both will ensure your DNS queries remain private
DNSSECDNSSEC
allows a user, application, or recursive resolver to trust that the
answer to their DNS query is what the domain owner intends it to be.
Put
another way: DNSSEC proves authenticity and integrity (though not
confidentiality) of a response from the authoritative name server. Doing
so makes it much harder for a bad actor to inject malicious DNS records
into the resolution path through BGP leaks and cache poisoning. This
type of tampering can allow an attacker to divert all traffic to a
server they control or stop the encryption of SNI, exposing the hostname
you are connecting to.
Cloudflare provides free DNSSEC support to everyone. You can read more about DNSSEC and Cloudflare at https://www.cloudflare.com/dns/dnssec/.
TLS 1.3TLS 1.3 is the latest version of the TLS protocol and contains many improvements for performance & privacy.
If
you're not using TLS 1.3, then the certificate of the server you are
connecting to is not encrypted, allowing anyone listening on the
Internet to discover which websites you are connecting to.
All
websites on Cloudflare get TLS 1.3 support enabled as default - you can
check your setting at any time by visiting the crypto section of the
Cloudflare dashboard. To read more about TLS 1.3 visit https://www.cloudflare.com/learning-resources/tls-1-3/
As a website visitor you should ensure you are using a browser which supports TLS 1.3 today by visiting this page and choosing a compatible browser.
Secure SNIEncrypted
Client Hello (ECH) is an extension of the TLS handshake protocol that
prevents privacy-sensitive parameters of the handshake from being
exposed to anyone between you and Cloudflare. This protection extends to
the Server Name Indication (SNI), which would otherwise expose the
hostname that you want to connect to when establishing a TLS connection.
ECH
is not yet widely available for web services behind Cloudflare, but we
are working closely with browser vendors on the implementation and
deployment of this important privacy enhancement for TLS. Read more in
the blog post introduction to ECH and our more recent update on the process of making this protection more widespread.
from https://www.cloudflare.com/ssl/encrypted-sni/
-----------------------------------------------------------------------
ECH隐私保护与SNI白名单
近日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是明文发送，数据途经的任何一个节点都能知道用户在访问哪个网站（虽然看不到网址等具体信息）。
https数据交互流程最初解决SNI明文的提案是ESNI，目前已经被ECH取代。其原理是将原来的Client Hello拆成两部分，外部消息中的SNI是共享的(例如cloudflare-ech.com)，内部消息中的SNI才是真实的。在Cloudflare的方案中，真实的SNI只有用户、CF和服务器知道，从而解决了SNI泄漏问题，这也就是为什么CF说这是隐私的最后一块拼图。
引入ECH的HTTPS数据交互如果你的网站使用了CF中转并且是免费计划（白嫖用户），恭喜你，相当于服务端已经默认帮你开启了ECH支持了，用户端开启ECH就能用上最先进的ECH保护了。使用其它CDN或者web服务器的，可能需要等待相关软件支持了（毕竟Nginx才刚把http3/quic支持加上）。
ECH依赖一种新型的DNS记录，因此ECH基于DoH的，这也为为什么ECH需要在DoH成熟可用后才推出。在Firefox 118及以上版本浏览器中，启用DoH就会开启ECH，其中DoH提供商可以选择CF或者其他家。
PS：目前只有Firefox强制ECH依赖于DoH，但ECH应该可以在不开启DoH的情况下使用。
火狐开启DoH和ECH。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解决的仅仅是用户到服务器之间的隐私问题，实际中还有非常多的隐私泄漏情况：浏览器、输入法、操作系统等，甚至键盘等都可能收集数据上传，想要保护好隐私还真不是一件容易的事情。普通用户所能做的，就是尽量远离流氓软件，少用没有数据加密的软件或者硬件，毕竟随便去个小区都有可能让你登记身份证号、手机号，没人会在意你的隐私。
参考文章：
Traditionally, DNS queries are sent in plaintext. Anyone listening on the Internet can see which websites you are connecting to.
To ensure your DNS queries remain private, you should use a resolver that supports secure DNS transport such as DNS over HTTPS (DoH) or DNS over TLS (DoT).
The fast, free, privacy focused 1.1.1.1 resolver supports DNS over TLS (DoT), which you can configure by using a client that supports it. For a list of these take a look here. DNS over HTTPS can be configured in Firefox today using these instructions. Both will ensure your DNS queries remain private
DNSSEC allows a user, application, or recursive resolver to trust that the answer to their DNS query is what the domain owner intends it to be.
Put another way: DNSSEC proves authenticity and integrity (though not confidentiality) of a response from the authoritative name server. Doing so makes it much harder for a bad actor to inject malicious DNS records into the resolution path through BGP leaks and cache poisoning. This type of tampering can allow an attacker to divert all traffic to a server they control or stop the encryption of SNI, exposing the hostname you are connecting to.
Cloudflare provides free DNSSEC support to everyone. You can read more about DNSSEC and Cloudflare at https://www.cloudflare.com/dns/dnssec/.
TLS 1.3 is the latest version of the TLS protocol and contains many improvements for performance & privacy.
If you're not using TLS 1.3, then the certificate of the server you are connecting to is not encrypted, allowing anyone listening on the Internet to discover which websites you are connecting to.
All websites on Cloudflare get TLS 1.3 support enabled as default - you can check your setting at any time by visiting the crypto section of the Cloudflare dashboard. To read more about TLS 1.3 visit https://www.cloudflare.com/learning-resources/tls-1-3/
As a website visitor you should ensure you are using a browser which supports TLS 1.3 today by visiting this page and choosing a compatible browser.
Encrypted Client Hello (ECH) is an extension of the TLS handshake protocol that prevents privacy-sensitive parameters of the handshake from being exposed to anyone between you and Cloudflare. This protection extends to the Server Name Indication (SNI), which would otherwise expose the hostname that you want to connect to when establishing a TLS connection.
ECH
is not yet widely available for web services behind Cloudflare, but we
are working closely with browser vendors on the implementation and
deployment of this important privacy enhancement for TLS. Read more in
the blog post introduction to ECH and our more recent update on the process of making this protection more widespread.
from https://www.cloudflare.com/ssl/encrypted-sni/
-----------------------------------------------------------------------
ECH隐私保护与SNI白名单
近日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是共享的(例如cloudflare-ech.com)，内部消息中的SNI才是真实的。在Cloudflare的方案中，真实的SNI只有用户、CF和服务器知道，从而解决了SNI泄漏问题，这也就是为什么CF说这是隐私的最后一块拼图。
如果你的网站使用了CF中转并且是免费计划（白嫖用户），恭喜你，相当于服务端已经默认帮你开启了ECH支持了，用户端开启ECH就能用上最先进的ECH保护了。使用其它CDN或者web服务器的，可能需要等待相关软件支持了（毕竟Nginx才刚把http3/quic支持加上）。
ECH依赖一种新型的DNS记录，因此ECH基于DoH的，这也为为什么ECH需要在DoH成熟可用后才推出。在Firefox 118及以上版本浏览器中，启用DoH就会开启ECH，其中DoH提供商可以选择CF或者其他家。
PS：目前只有Firefox强制ECH依赖于DoH，但ECH应该可以在不开启DoH的情况下使用。
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解决的仅仅是用户到服务器之间的隐私问题，实际中还有非常多的隐私泄漏情况：浏览器、输入法、操作系统等，甚至键盘等都可能收集数据上传，想要保护好隐私还真不是一件容易的事情。普通用户所能做的，就是尽量远离流氓软件，少用没有数据加密的软件或者硬件，毕竟随便去个小区都有可能让你登记身份证号、手机号，没人会在意你的隐私。
参考文章：
No comments:
Post a Comment