托管在Cloudflare上的网站绕过了Cato防火墙

问题

Cato防火墙未能在托管在Cloudflare上的网站上强制执行防火墙规则。 例如，网站research.cloudflare.com被分类为数据库，尽管有防火墙规则阻止此类别，仍被允许。

相关的CMA事件显示了不同的域名cloudflare-ech.com，这与预期的站点不匹配并绕过了防火墙规则。 可以通过过滤网站的目的IP地址找到此事件。

环境

• 防火墙规则阻止特定类别。
• 未启用TLS检查。

故障排除

事件中出现域名cloudflare-ech.com表明正在使用加密客户端Hello（ECH）协议。

ECH是什么？

正如Cloudflare 文档中所述，ECH 加密了 TLS 客户端 Hello 数据包的部分内容，包括掩盖服务器名称指示（SNI），后者通常用于建立 TLS 会话。 这意味着虽然Cato看到了到Cloudflare的连接，但它无法识别特定的网站。 客户端和网站都必须支持ECH才能正常工作。

ECH的工作原理

1. 公钥分发：服务器通过 DNS 共享公开密钥（在 ECH 配置中），通常使用安全的 DNS 协议如 DoH（超文本传输协议安全上的 DNS）或 DoT（TLS 上的 DNS）。 然而，也可以使用通过UDP的未加密DNS。 客户端使用该密钥加密Client Hello消息。 下面是一个包含ECH配置的HTTPS类型DNS回复示例。
   
2. 客户端Hello加密：连接时，客户端使用服务器的公钥加密Client Hello的敏感部分，如SNI。 只有服务器可以解密此信息。 另外还传输了一个未加密的外部Client Hello，显示如默认SNI的通用信息，这可能不会揭示真正的目标。 在下面的示例中，默认SNI是cloudflare-ech.com
   
3. 备用机制：如果支持ECH，服务器处理已加密的Client Hello，并继续连接。 如果不支持，备用机制会重试连接，使用未加密的Client Hello，保持与传统TLS 1.3服务器的向后兼容性。

解决方案

Cato当前不支持ECH，因此建议以下解决方法根据您的网络设置强制回退到未加密SNI的TLS连接：

• 在互联网防火墙中阻止DoH、DoT和QUIC协议。 这将阻止使用安全的DNS协议交换ECH配置。
  
• 根据浏览器，客户端可能会回退到基于UDP的DNS来交换ECH配置。 如果是，请为受影响的站点或用户启用TLS 检查。 ECH 不支持中间人攻击（MITM）技术，因此连接将回退到使用未加密的 SNI。
• 作为最后手段，在互联网防火墙中阻止域名cloudflare-ech.com。 这将迫使浏览器回退到未加密的SNI，从而允许应用正确的防火墙规则。