Filter HTTPS content & enforce Captive Portal without MITM proxy

captive-portalcontent-filterfilteringhttpsuntangle

My church wants to start providing free WiFi to our guests, but with 2 requirements:

  • Inappropriate content (such as Pornography and Warez) must be filtered out.
  • The end-user must create an account and agree to our terms & conditions (Captive Portal).

Currently we're running an instance of Untangle with the Web Filter, HTTPS Inspector and Captive Portal add-ons.

This works great with one exception: when a user first connects to our WiFi, we have to ask them to install our CA root certificate to be able to MITM their HTTPS traffic to filter out bad content or they get a message like this when trying to go to any site over HTTPS:

IE Certificate Error

Which is quite a barrier to entry especially for Internet Explorer users as the process to import a root certificate can be long and confusing for non technical people.

We also have a number of on-site machines that need the root certificate, but we can roll it out to those with an Active Directory GPO so that's not a problem.

We've also considered the following options:

  • Using a WPAD.DAT file to send the users through our filter: this seems unreliable (many browsers have it turned off by default).

  • Blocking content by IP: this means maintaining an IP blacklist, and the end-user gets a "connection refused" message instead of an explanation of why we've blocked that content.

  • Using SNI to block content: Untangle supports this out the box, but it has the same problem as blocking by IP ("connection refused" message).

This problem also affects our captive portal, as we need to redirect users to the captive portal to log in – which is impossible over HTTPS without MITM the request / response.

Am I missing something? Is there another approach to solving this problem that is easier for the end-user / doesn't require them to do anything?

Best Answer

Consider the question you're asking ("How can I serve a blockpage instead of https://playboy.com without my users having to do anything") as "How can I serve my own version of https://trusted-bank.com without my users' knowledge".

HTTPS and browsers are (these days) designed to avoid exactly this. This makes web filtering hard.

Even if you pushed a wpad, and as such have an explicit proxy, you can still only refuse connections to "bad" sites, though it does solve sni-related issues, it really doesn't get you that much further on (with this part of the problem, at least).

In terms of serving a login page, wispr is useful for informing the user they have to log in.

Related Topic