Mozilla 宣布为 Firefox 稳定分支的用户提供对 ECH（加密客户端 Hello）机制的支持，该机制延续了 ESNI（加密服务器名称指示）技术的发展，旨在加密有关 TLS 会话参数的信息，例如请求的域名。 使用 ECH 的代码最初添加到 Firefox 85 版本中，但默认情况下处于禁用状态。 从 Chrome 115 的发布开始，Chrome 逐渐开始包含 ECH 支持。
除了与……联系 服务器 请求的域名信息会通过 DNS 泄露。为了获得全面保护，除了 ECH 之外，您还必须使用 DNS over HTTPS 或 DNS over TLS 来加密 DNS 流量。如果您未在设置中启用 DNS over HTTPS，Firefox 将无法使用 ECH。您可以在此页面上检查您的浏览器是否支持 ECH。
在 Firefox 中默认启用 ECH 支持的因素之一是 Cloudflare 几天前在其内容交付网络中包含了 ECH 支持。 在实际方面，由于使用 ECH 时有关请求主机的数据在分析中是隐藏的，因此使用 Cloudflare CDN 过滤和阻止不需要的站点现在需要阻止整个 Cloudflare 网络、阻止来自 ECH 的所有请求或使用虚假根证书组织 HTTPS 拦截在用户系统上。
最初，为了在多个 HTTPS 站点的一个 IP 地址上组织工作，使用了 TLS 扩展 SNI，其中在建立加密通信通道之前传输的 ClientHello 消息中指示了请求的主机的名称。 此功能使得在连接处理的早期阶段可以跨虚拟主机分发请求，但也使得 ISP 端可以有选择地过滤 HTTPS 流量并分析用户打开了哪些站点，这在使用时无法实现完全保密HTTPS。
为了解决这个问题并防止泄漏所请求站点的信息，后来提出了 ESNI 扩展，通过主机名实现数据加密。 在 ESNI 的实施过程中，人们发现所提出的机制并没有涵盖所有可能的主机数据泄露源，并且其使用不足以确保 HTTPS 会话的完全机密性。 特别是，当恢复先前建立的会话时，在PSK（预共享密钥）TLS扩展的参数中继续指定明文域名。 此外，实施 ESNI 的努力已发现兼容性和扩展问题，这些问题阻碍了 ESNI 的广泛采用。
考虑到 ESNI 已发现的缺点，开发了一种新的通用 ECH 机制，允许对任何 TLS 扩展的参数进行加密。 从技术上讲，ECH 和 ESNI 之间的主要区别在于，不是单个字段，而是整个 ClientHello 消息立即加密。 ECH 涉及将 ClientHello 分成两个单独的消息 - 加密的 ClientHelloInner 消息（SNI Inner）和未加密的底层 ClientHelloOuter 消息（SNI Outer）。 未加密的 SNI Outer 携带非隐私数据，例如 TLS 版本和使用的密码列表，以及与请求域的实际名称不重叠的通用域名。 例如，对于所有 Cloudflare 客户端，未加密的 SNI Outer 指定公共主机“cloudflare-ech.com”，但请求主机的实际名称在加密的 SNI Inner 中传输，无法用于分析。
ECH 还采用了不同的加密密钥分发方案：公钥信息通过 HTTPSSVC DNS 记录而非 TXT 记录进行传输。基于 HPKE（混合公钥加密）机制的端到端认证加密用于获取和加密密钥。ECH 还支持从服务器安全重传密钥，这可在密钥轮换时使用。 服务器 并解决从 DNS 缓存中检索过期密钥的问题。
来源： opennet.ru
