中国已开始阻止使用 TLS 1.3 和 ESNI 建立的 HTTPS 连接

中国 实施的 锁 所有使用 TLS 1.3 协议和 ESNI（加密服务器名称指示）TLS 扩展的 HTTPS 连接，该扩展提供有关所请求主机的数据加密。 对于从中国到外界以及从外界到中国建立的连接，都会在中转路由器上进行阻止。

阻止是通过将数据包从客户端丢弃到服务器来完成的，而不是之前由 SNI 内容选择性阻止执行的 RST 数据包替换。 当触发 ESNI 封包后，源 IP、目的 IP 和目的端口号组合对应的所有网络封包也会被封堵 120 到 180 秒。 基于旧版本 TLS 和 TLS 1.3（不带 ESNI）的 HTTPS 连接照常允许通过。

让我们回想一下，为了在多个 HTTPS 站点的一个 IP 地址上组织工作，开发了 SNI 扩展，该扩展在安装加密通信通道之前传输的 ClientHello 消息中以明文形式传输主机名。 此功能使得互联网提供商可以有选择地过滤 HTTPS 流量并分析用户打开的网站，但在使用 HTTPS 时无法实现完全保密。

新的 TLS 扩展 ECH（以前称为 ESNI）可与 TLS 1.3 结合使用，消除了这一缺点，并完全消除了分析 HTTPS 连接时所请求站点的信息泄漏。 与通过内容交付网络进行访问相结合，ECH/ESNI 的使用还可以向提供商隐藏所请求资源的 IP 地址。 流量检查系统只会看到对 CDN 的请求，并且无法在没有 TLS 会话欺骗的情况下应用阻止，在这种情况下，有关证书欺骗的相应通知将显示在用户的浏览器中。 DNS 仍然是一个可能的泄漏渠道，但客户端可以使用 DNS-over-HTTPS 或 DNS-over-TLS 来隐藏客户端的 DNS 访问。

研究人员已经 确定 有几种解决方法可以绕过客户端和服务器端的中文阻止，但它们可能变得无关紧要，只能被视为临时措施。 例如，当前仅包含 ESNI 扩展 ID 0xffce（加密服务器名称）的数据包，该数据包用于 标准草案第五版，但目前数据包的当前标识符为 0xff02 (encrypted_client_hello)，建议在 ECH 规范第七稿.

另一种解决方法是使用非标准连接协商过程，例如，如果提前发送序列号不正确的附加 SYN 数据包，则阻塞不起作用、使用数据包碎片标志进行操作、发送同时包含 FIN 和 SYN 的数据包设置标志、用不正确的控制量替换 RST 数据包或在使用 SYN 和 ACK 标志的数据包连接协商开始之前发送。 所描述的方法已经以工具包插件的形式实现 日内瓦, 发达 绕过审查方法。

来源： opennet.ru