背景
SNI 通过让客户端发送虚拟域的名称作为 TLS 协商的ClientHello消息的一部分来解决此问题。[3]这使服务器能够尽早选择正确的虚拟域，并向浏览器提供包含正确名称的证书。因此，对于实现 SNI 的客户端和服务器，具有单个 IP 地址的服务器可以为一组域名提供服务，而这些域名无法获得通用证书。
2003 年 6 月，通过 RFC 3546，传输层安全 (TLS) 扩展， SNI 被添加到IETF的互联网 RFC中。该标准的最新版本是 RFC 6066。
隐患
服务器名称指示负载未加密，因此客户端尝试连接的服务器的主机名对被动窃听者可见。安全软件利用此协议弱点进行网络过滤和监控[4] [5] [6]以及政府实施审查。[7]目前，有多种技术试图隐藏服务器名称指示。
ECH - 加密客户端 Hello
Encrypted Client Hello ( ECH ) 是 TLS 1.3 协议扩展，可以对在 TLS 1.3 协商的早期发送的整个 Client Hello 消息进行加密。ECH 使用依赖方（Web 浏览器）需要事先知道的公钥对有效负载进行加密，这意味着 ECH对于浏览器供应商事先已知的 大型CDN最有效。
此扩展的初始 2018 版本称为加密 SNI ( ESNI ) [10]，其实现以"实验性"方式推出，以解决域窃听的风险。[11] [12] [13] Firefox 85 移除了对 ESNI 的支持。[14]与 ECH 相比，加密 SNI 仅加密 SNI 而不是整个 Client Hello。[15] 2018 年 10 月[16] Firefox 纳入了对该版本的选择支持，并且需要启用 DNS-over-HTTPS。[17]
2020 年 3 月，经过分析证明仅加密 SNI 是不够的，ESNI 被重新设计为 ECH 扩展。例如，规范允许预共享密钥扩展包含任何数据以促进会话恢复，甚至传输由 ESNI 加密的与服务器名称完全相同的明文副本。此外，逐一加密扩展将需要每个扩展的加密变体，每个都有潜在的隐私隐患，甚至会暴露所宣传的扩展集。最后，ESNI 的实际部署暴露了互操作性限制。[18] 2020年3月简称ECHO [15] 2020年5月改为ECH [19]
ESNI 和 ECH 仅与 TLS 1.3 兼容，因为它们依赖于 TLS 1.3 中首次定义的 KeyShareEntry。[20] [21]此外，要使用 ECH，客户端不得提议低于 1.3 的 TLS 版本。[22]
2020 年 8 月，中国防火墙开始阻止 ESNI 流量，同时仍允许 ECH 流量。[23]
2020 年 10 月，俄罗斯 ISP Rostelecom及其移动运营商Tele2开始阻止 ESNI 流量。[24]同年9月，俄罗斯审查部Roscomnadzor计划禁止一系列加密协议，其中包括阻碍网站访问审查的TLS 1.3和ESNI。[25] [26] [27]
博文
没有评论:
发表评论