Certificate Errors on “redirection” in DNS RPZ of https/ssl

dns-firewalldomain-name-systemhttpsredirectionrpz

I've set up a DNS RPZ where I "redirect" users to a walled garden using DNS RPZ records when users try to access a list of bad sites.

Let's say a user tries to access badsite.com. The redirection to my walled garden for http connections works but for https connections it causes certificate errors because the URL in the browser remains the same (badsite.com) but the resolved IP is connecting to my walled garden (walledgarden.example.com).

Is there any way to resolve the certificate errors when using DNS RPZ for redirection on https connections?

Best Answer

For a moment, I want you to pretend you are a malware author who has successfully compromised the DNS servers of your company. You are trying to use DNS to serve bogus IP addresses whenever someone tries to visit a bank. Unfortunately, you can't get those confounded browser warnings to go away when HTTPS gets invoked.

That's basically what you're asking us to help you with. Your intentions are benign compared to this supposed malware author, but that doesn't change the fact that the technology is working as intended here. You cannot design security around intent.

Since the policy action occurs at the DNS level, there's no way to know whether the user is using HTTP or HTTPS at the time the query is sent. The only thing you can control is whether or not you're going to return an IP address, and what that IP address is.

Once you've arrived at this point, this is a basic HTTPS hijacking scenario. All the same rules apply. If you're in a position to manipulate the trusted CAs, you can manipulate the browsers. Other than that, no dice.

You have four options here:

  1. Follow the suggestion of sebix in the comments: push a CA cert to every workstation that will be subject to this RPZ protection. If this is an enterprise, it's perfectly doable and in the best case scenario such a CA cert might exist already.
  2. Deal with things as they are now, which provides a way for people to see a description of why they aren't getting to the site in question.
  3. Change your rewrite to prevent them from getting a webpage at all. Instead of sending them to a webpage, "eat" the query with rpz-drop., CNAME . (NXDOMAIN), or CNAME *. (NODATA).
  4. Choose an IP address that will always refuse the port 443 connection and give it an A record that suggests what is going at the policy level. Have your rewrite CNAME point to this record. This will at least give a technical person some sort of breadcrumb to find when they begin troubleshooting. Obviously these technical people will be in the minority, but it's better than nothing.

An example of #4 would be something like this:

# 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
Related Topic