Filtrar conteúdo HTTPS e impor o Captive Portal sem o proxy MITM

Question

Minha igreja quer começar a fornecer Wi-Fi gratuito para nossos hóspedes, mas com dois requisitos:

• O conteúdo impróprio (como Pornografia e Warez) deve ser filtrado.
• O usuário final deve criar uma conta e concordar com nossos termos & condições (Portal Cativo).

Atualmente, estamos executando uma instância de Untangle com o Filtro da Web , Inspetor HTTPS e Portal do Responsável add-ons.

Isso funciona muito bem com uma exceção: quando um usuário se conecta pela primeira vez ao nosso Wi-Fi, precisamos pedir a eles para instalar nosso certificado raiz da CA para poder usar o tráfego HTTPS do MITM para filtrar conteúdo ruim ou receber uma mensagem como essa ao tentar acessar qualquer site por HTTPS:

Oqueéumagrandebarreiraàentrada,especialmenteparausuáriosdoInternetExplorer,poisoprocessoparaimportarumcertificadoraizpodeserlongoeconfusoparapessoasnãotécnicas.

Tambémtemosváriasmáquinason-sitequeprecisamdocertificadoraiz,maspodemosdistribuí-lasparaaquelescomumGPOdoActiveDirectory,paraqueissonãosejaumproblema.

Tambémconsideramosasseguintesopções:

• Usandoum arquivo WPAD.DAT para enviar os usuários pelo nosso filtro: isso não parece confiável (muitos navegadores estão desativados por padrão).

• Bloqueio de conteúdo por IP: isso significa manter uma lista negra de IP, e o usuário final recebe uma mensagem de "conexão recusada" em vez de explicar por que bloqueamos esse conteúdo.

• Usando SNI para bloquear o conteúdo: Desembaraçar suporta esta caixa, mas tem o mesmo problema que o bloqueio por IP (mensagem "conexão recusada").

Esse problema também afeta nosso portal cativo, já que precisamos redirecionar os usuários para o portal cativo para efetuar login - o que é impossível em HTTPS sem MITM a solicitação / resposta.

Estou faltando alguma coisa? Existe outra abordagem para resolver este problema que é mais fácil para o usuário final / não exige que ele faça nada?

    

Answer 1

Considere a pergunta que você está fazendo ("Como posso exibir um bloqueio em vez do link sem que meus usuários tenham que fazer nada") como " Como posso servir minha própria versão do link sem o conhecimento dos meus usuários ".

HTTPS e navegadores são (atualmente) projetados para evitar exatamente isso. Isso dificulta a filtragem da Web.

Mesmo que você tenha pressionado um wpad e, como tal, tenha um proxy explícito, ainda é possível recusar conexões a sites "ruins", embora ele resolva problemas relacionados a sni, mas isso não o leva muito além (com essa parte do problema, pelo menos).

Em termos de veicular uma página de login, o wispr é útil para informar ao usuário que ele deve fazer o login.

    

Answer 2

Como é o público que você está atendendo, sinto que não é possível pedir a eles que instalem seu certificado raiz SSL (como eles sabem que você não os ajustará em suas conexões domésticas?). O processo para isso também é muito técnico e varia de acordo com o navegador.

Sinto que suas opções são manter uma lista negra de IPs ou desabilitar totalmente as conexões https. Para a lista negra de IPs, sim, eles verão apenas "conexão recusada" em vez de uma página de erro personalizada, mas você realmente precisa explicar por que o acesso a warez ou pornografia foi bloqueado? Desativar o https significa que as pessoas não poderão acessar alguns sites específicos, mas sim se as pessoas realmente precisam acessá-los na igreja ou se você quer que algum intruso entre em seus sinais abertos de wifi possa interceptar suas conexões com eles . Talvez para compensar, você pode permitir https (através de seu certificado raiz e interceptar proxy) nos computadores da igreja, caso as pessoas realmente precisem usar esses sites.