Enviado em 26/10/2016 - 15:30h
Vou abrir um tópico dedicado mas como existe a dúvida neste tópico também:
Pessoal quem utiliza Squid + C-ICAP ou qualquer outro servidor ICAP provavelmente já se deparou com o seguinte problema:
Em um cenário onde com proxy não-transparente e sem certificados nas maquinas o Squid/ICAP retorna um erro que não é "entendido" pelo navegador que exibe uma mensagem própria como se o site estivesse fora do ar, o problema afeta também Endian Firewall, Pfsense e outras distribuições de FW.
Mas a solução foi encontrada pelo pessoal da Diladele, um server ICAP que também trabalha com o Squid mas tem apenas versão trial de 30 dias e comercial, tornando-o inviavel para quem trabalha apenas com Open Source.
Antes de mais nada segue a analise deles do problema:
Se na sua rede os navegadores utilizam um proxy explicito (Configurado no navegador, não transparente) ao navegar para um site HTTPS bloqueado a sequência de eventos abaixo ocorre:
1-O navegador estabelece uma conexão HTTP normal ao proxy server e envia o pedido CONNECT facebook.com:443 para configurar o tunel seguro ao Facebook.
2- O Squid intercepta este pedido e o redireciona ao servidor ICAP
3- O servidor ICAP "vê" que o dominio facebook.com está bloqueado e retorna um mensagem HTTPS "403 Blocked" ao Squid.
4- O Squid encaminha o "403 Blocked" de volta para o navegador
5- O Navegador espera receber o Handshake SSL do Facebook e ao invés disto vê um fluxo inesperado de bytes (a resposta 403) e mostra uma mensagem padrão do próprio navegador "Não é possível conectar ao site utilizando HTTPS" ao invés da página de erro do Squid.
A solução no caso é primeiro deixar o tunel CONNET ser bem sucedido e depois bloquear o primeiro pedido neste tunel.
O problema está sendo implementar a solução da Diladele no Endian e no Squid +ICAP utilizado pela comunidade em geral.
Perguntei ao Rafael da Diladele se o "segredo" eram somentes as ACLS que ele criou combinadas com SSL Bump já disponível no Squid e ele me disse que sim então a base seria o código abaixo
# No caso forçamos o sslbump a habilitar o bloqueio "atrasado" de túneis CONNECT, funciona apenas em modo não transparente, adicionando um header "X-SSL-Bump: force" ao pedido CONNECT
acl qlproxy_ssl_force_bump req_header X-SSL-Bump -i force
A diladele fornece uma vm já configura com o sistema (baixe a versão 4.7 que tem a licença trial válida ainda por 30 dias) para quem quiser analisar o funcionamento do sistema, testei aqui e realmente a mensagem de erro está sendo exibida, só lembre de marcar a opção no filtro do proxy.
Agora o negócio é implementar esta solução no Squid + qualquer servidor ICAP. Idéias pessoal?
Thanks!
(Meu Squid.conf atual "puro" sem as regras extras, já tentei algumas váriavies mas ainda sem sucesso, se no tempo do pessoal aqui analisar eu conseguir a solução, postarei aqui visto que é um problema que já tem anos e só agora veio uma solução prática que não envolva ter que instalar um certificado em cada máquina da rede, no meu caso com redes com 3/4 mil usuários é totalmente inviável especialmente porque nem todos estão no AD)
# +------------------------------------------------------------------------------+http://www.fsf.org/ |
