https/ssl 的 DNS RPZ 中“重定向”的证书错误

https/ssl 的 DNS RPZ 中“重定向”的证书错误

我已经设置了一个 DNS RPZ,当用户尝试访问不良网站列表时,我会使用 DNS RPZ 记录将用户“重定向”到围墙花园。

假设用户尝试访问 badsite.com。对于 http 连接,重定向到我的围墙花园是可行的,但对于 https 连接,它会导致证书错误,因为浏览器中的 URL 保持不变 (badsite.com),但解析后的 IP 连接到我的围墙花园 (walledgarden.example.com)。

有没有办法解决使用 DNS RPZ 进行 https 连接重定向时出现的证书错误?

答案1

暂时,我想让你假装自己是一名恶意软件作者,已经成功入侵了公司的 DNS 服务器。每当有人试图访问银行时,你都会尝试使用 DNS 提供虚假 IP 地址。不幸的是,当调用 HTTPS 时,你无法让那些令人困惑的浏览器警告消失。

这基本上就是你要求我们帮助你解决的问题。与这个所谓的恶意软件作者相比,你的意图是善意的,但这并不能改变该技术在这里按预期发挥作用的事实。您不能围绕意图来设计安全性。


由于策略操作发生在 DNS 级别,因此无法知道用户在发送查询时使用的是 HTTP 还是 HTTPS。您唯一可以控制的是您是否要返回 IP 地址以及该 IP 地址是什么。

一旦你到达这一点,这就是一个基本的 HTTPS 劫持场景。所有相同的规则都适用。如果你有能力操纵受信任的 CA,你就可以操纵浏览器。除此之外,别无选择。

这里有四个选项:

  1. 按照评论中 sebix 的建议:将 CA 证书推送到将受到此 RPZ 保护的每个工作站。如果这是企业,则完全可行,并且在最佳情况下,此类 CA 证书可能已经存在。
  2. 按现状处理事情,这为人们提供了一种方式来了解他们为什么无法进入相关站点的描述。
  3. rpz-drop.更改您的重写,以防止他们获取网页。不要将他们发送到网页,而是使用、CNAME .(NXDOMAIN) 或CNAME *.(NODATA) “吞噬”查询。
  4. 选择一个始终拒绝端口 443 连接的 IP 地址,并为其提供一条A记录,以表明策略级别正在发生什么。让您的重写CNAME指向此记录。这至少会为技术人员在开始故障排除时提供某种线索。显然,这些技术人员将是少数,但总比没有好。

#4 的一个例子如下:

# RPZ zone file
$ORIGIN example.rpz.
badsite IN CNAME filtered-malware-site.example.com.

# normal zone file
$ORIGIN example.com.
filtered-malware-site IN A 203.0.113.1

相关内容