过滤HTTPS内容并在没有MITM代理的情况下执行Captive Portal

我的教会想要开始为我们的客人提供免费的WiFi，但有2个要求：

不适当的内容（如色情和Warez）必须被滤除。
最终用户必须创build一个帐户，并同意我们的条款和条件（强制门户网站）。

目前我们正在使用Web Filter ， HTTPS Inspector和Captive Portal插件运行一个Untangle实例。

除了一个例外：当用户第一次连接到我们的WiFi时，我们不得不要求他们安装我们的CA根证书，以便能够MITM他们的HTTPSstream量来过滤掉不好的内容，或者当他们试图通过HTTPS访问任何网站：

IE证书错误

这对进入Internet Explorer的用户来说是一个相当大的障碍，因为导入根证书的过程对于非技术人员来说可能是漫长而令人困惑的。

我们还有许多需要根证书的现场机器，但是我们可以将它推出给那些使用Active Directory GPO的机器，这不是问题。

我们还考虑了以下选项：

使用WPAD.DAT文件通过我们的filter发送用户：这似乎是不可靠的（许多浏览器默认closures它）。
按IP封锁内容：这意味着维护一个IP黑名单，并且最终用户得到“拒绝连接”的消息，而不是解释为什么我们阻止了这个内容。
使用SNI阻止内容： Untangle支持这种方式，但它具有与IP阻塞相同的问题（“拒绝连接”消息）。

这个问题也影响了我们的强制门户，因为我们需要将用户redirect到强制门户进行login – 如果没有MITM请求/响应，这是不可能的。

我错过了什么吗？有没有解决这个问题的另一种方法，最终用户更容易/不需要他们做任何事情？

考虑你问的问题（“我怎样才能服务封锁，而不是https://playboy.com没有我的用户不得不做任何事情”）作为“我怎样才能服务我自己的版本的https&#xFF1A://可信银行.com没有我的用户的知识“。

HTTPS和浏览器（现在）都是为了避免这种情况而devise的。这使得Web过滤变得困难。

即使你推了一个wpad，而且有一个明确的代理，你仍然可以拒绝连接到“坏”的网站，虽然它确实解决了sni相关的问题，但它并没有让你更进一步（与此至less是部分问题）。

就提供login页面而言，wispr对于通知用户他们必须login很有用。

因为它是你所需要的公众，所以我觉得你不能合理地要求他们安装你的SSL根证书（他们怎么知道你不会在他们的家庭连接上连接它们？）。这个过程也是非常技术性的，因浏览器而异。

我觉得你的select是维护一个IP黑名单，或完全禁用https连接。对于IP黑名单，是的，他们只会看到“连接被拒绝”而不是自定义的错误页面，但是你是否真的需要解释为什么访问warez或色情内容被阻止？禁用https意味着人们将无法访问某些特定的网站，但想想在教堂时是否真的需要访问这些网站，或者是否希望任何入侵者打开您的开放式无线信号，以便能够拦截与他们的连接。也许为了补偿，你可以在教堂所有的计算机上允许https（通过你的根证书和拦截代理），以防人们真的需要使用这些网站。