2

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?

Improve this question
3
  • 4
    No there isn't. One of the points in using HTTPS is making it impossible to unknowingly eavesdrop on users.
    – Tero Kilkanen
    Commented Apr 19, 2015 at 9:49
  • I would recommend against any solution that required end-users to accept a new root-certificate... If/when this cert leaks, all your users will be in trouble. Basically you are MITM-ing. If you don't want to allow traffic to certain sites, block them on IP, not on SSL level.
    – Sig-IO
    Commented Apr 20, 2015 at 13:47
  • Also... would you WANT to intercept any possible banking traffic... which you have now decrypted on your gateway.
    – Sig-IO
    Commented Apr 20, 2015 at 13:48

3 Answers 3

Reset to default
3

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.

Improve this answer
1
  • Thanks for the confirmation and Wispr recommendation - just needed a second opinion I can take back to my pastor :)
    – Daniel Upton
    Commented Apr 27, 2015 at 12:15
1

As it is the public you are catering to, I feel you cannot reasonably ask them to install your SSL root certificate (how do they know you won't then mitm them on their home connections?). The process for this is also very technical and varies by browser.

I feel your options are to maintain an IP blacklist, or to disable https connections entirely. For the IP blacklist, yes, they will only see "connection refused" instead of a custom error page, but do you really need to explain why access to warez or pornography was blocked? Disabling https means people won't be able to go to some specific websites - but think about whether people really need to access these while at church, or whether you want any intruder into your open wifi signals to be able to intercept their connections to them. Perhaps to compensate, you could allow https (through your root certificate and intercepting proxy) on the church-owned computers, in case people really need to use these sites.

Improve this answer
2
  • Thanks John, you're quite right it's unreasonable - I just needed to get a second opinion to prove it to my pastor!
    – Daniel Upton
    Commented Apr 27, 2015 at 12:16
  • With more and more very popular sites using HSTS, including the church's Facebook Page if it has one, "some specific websites" is likely a large enough set to make the hotspot not very useful.
    – Damian Yerrick
    Commented Apr 29, 2016 at 23:51
0

You can setup transparent proxy on your gateway. For example on OpenWrt, it can be done using Tinyproxy and firewall rules. For SSL, you'll also need TCP to proxy redirector, like redsocks. However, current version of redsocks only uses HTTP 1.0 for communication with proxies. This prevents filtering on the Tinyproxy side (as filtering is based on HTTP 1.1 Location header). But I believe you can find alternative to redsocks, that supports HTTP 1.1.

Also check my gist, with instructions and links to other relevant sources.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .