https / ssl的DNS RPZ中的“redirect”证书错误

有一刻，我想让你假装你是一个恶意软件作者，他已经成功地破坏了你公司的DNS服务器。 当有人试图访问一家银行时，您正试图使用​​DNS来为虚假的IP地址提供服务。 不幸的是，当HTTPS被调用时，你不能让这些混淆的浏览器警告消失。

这基本上是你要求我们帮助你的。 与这个所谓的恶意软件作者相比，你的意图是良性的，但这并没有改变这个技术按照这个意图工作的事实。 您无法围绕意图devise安全性。

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

一旦你到达这一点，这是一个基本的HTTPS劫持情况。 所有相同的规则适用。 如果您有能力操纵可信任的CA，则可以操纵浏览器。 除此之外，没有骰子。

你有四个select：

1. 在注释中遵循sebix的build议：将CA证书推送到将受到此RPZ保护的每个工作站。 如果这是一个企业，这是完全可行的，在最好的情况下，这样的CA证书可能已经存在。
2. 处理现在的情况，这为人们提供了一种方式，让他们看到为什么他们没有进入相关网站。
3. 改变你的重写，以防止他们得到一个网页。 而不是将它们发送到网页，用rpz-drop. “吃”查询rpz-drop. ， CNAME . （NXDOMAIN）或CNAME *. （没有数据）。
4. select一个始终拒绝端口443连接的IP地址，并给它一个build议在策略级别进行的logging。 把你的重写CNAME指向这条logging。 这至less会让一个技术人员在开始排除故障时find某种面包屑。 显然，这些技术人员将是less数，但总比没有好。

＃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