This isn't urgent so please take some time to read it and provide feedback over the next few weeks.

As we work with MECnet on the next release of the Joebox (targeted to be ready for the fall) one of the things we're focus on is SSL filtering for MECguard. We haven't see much adoption of the proxy-based method for SSL filtering, so we're looking into the problems with that and how to make it better.

MECnet has provided us with a (rough) proof of concept transparent SSL filter.

With this model, the Joebox generates a custom root certificate authority, which it then uses to sign generated SSL certificates on-demand for SSL requests. This allows the Joebox to make the SSL request, decrypt the page, check the requested URL (which is normally encrypted), scan the content, and make a filtering determination the same way MECguard does for non-SSL requests today.

This means that filtering of specific URLs, not just domains, as well as page content becomes possible.

Upside:

MECguard configuration is normalized between HTTP and HTTPS; blocking something like "www.facebook.com/login.php" will successfully block both types of requests.
Log would show full URL for HTTPS requests (e.g. "https://www.facebook.com/login.php?id=banana" rather than "facebook.com" or an IP address).
MECguard would be able to scan page content, not just the URL, allowing RTF (keyword content scanning) to work.
Antivirus (if included, still in testing) would be able to check SSL content.
Doesn't affect browsing for laptops when off network (as having proxy servers configured can sometimes do).

Downside:

For users not to get certificate errors in their browser, they would need to install the root CA generated by the Joebox. Otherwise every request will generate an error.
Privacy concerns with the Joebox busting open encryption for SSL requests; would need to notify users that it is happening somehow (note that this process is contained in a single process which decrypts, scans, and encrypts; there is no way for a system administrator to actually see or log the unencrypted content).

Question:

Is the requirement of having to install a custom root CA a show stopper? If so, for what reasons (too much work to deploy; privacy or ethical concerns; etc)

The current thinking is that for those who need higher visibility and control than OpenDNS provides, the requirement of installing a custom root CA in the browser is worth while. Note that the SSL filtering will work without installing the root CA, it will just generate an SSL error for each website (but only for the first request; same behavior as websites that use self-signed certificates).