1. squid nao mostra pagina de erro quando bloqueia https [RESOLVIDO]
junior-123usa KUbuntu
Post recolhido
Enviado em 24/07/2013 - 18:22h
ola, montei um proxy. e parece tudo ok, mas quando um site que deve ser bloqueado eh acessado por https o squid não mostra a pagina de erro. alguem pode me ajudar?
quando esse bloqueio acontece o navegador mostra a mensagem: Firefox is configured to use a proxy server that is refusing connections.
Não consegui resolver este problema!!! Voce conseguiu?
5. Sem soluções
roselio_jantarausa Debian
Post recolhido
Enviado em 14/02/2014 - 20:47h
ivoneyborges escreveu:
Não consegui resolver este problema!!! Voce conseguiu?
Eu apanhei tanto do https que me contentei em apenas conseguir bloquear, bem na época que eles mudaram tinha acabado de montar 2 servidores proxy, se hoje ainda não tem muitas soluções imagine a 2 anos atrás!
Meu problema foi bloquear o Facebook,Twitter, Youtube e liberar os Bancos que também usam https (Porta 443), consegui por string no firewall.
E apesar de usar proxy transparente para que os ip's da diretoria naveguem sem bloqueio o proxy tem que estar setado no navegador! O restante navega oque ta na lista branca e bancos (https)sem problemas. Demorei 15 dias trabalhando 12 horas por dia pra chegar nesta solução!
Boa Sorte a vocês !
6. Re: squid nao mostra pagina de erro quando bloqueia https [RESOLVIDO]
carlosrvusa Outra
Post recolhido
Enviado em 15/10/2016 - 19:36h
Alguem conseguiu alguma solução para o problema acima ?
7. Re: squid nao mostra pagina de erro quando bloqueia https [RESOLVIDO]
gmjusa Ubuntu
Post recolhido
Enviado em 17/10/2016 - 10:18h
Bom dia,
Alguém encontrou alguma solução ?
Estou com o mesmo problema tb.
Não exibe a tela de bloqueio do squid nas paginas https, nas demais exibe.
Att
8. Re: squid nao mostra pagina de erro quando bloqueia https
removidousa Nenhuma
Post recolhido
Enviado em 17/10/2016 - 10:42h
Isto não é um erro. O proxy não entrega a página de erro quando bloqueia um site usando https por que ele só consegue ler o endereço com a porta, por que o próprio navegador informa o endereço. por exemplo www.site.com.br:443.
Se quer que o proxy leia as informações para fazer filtros mais elaborados e o mesmo entregar as páginas de bloqueio do squid, o squid precisa trabalhar como man-in-the-middle.
9. Re: squid nao mostra pagina de erro quando bloqueia https
GeekZillausa CentOS
Post recolhido
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
ssl_bump server-first qlproxy_ssl_force_bump
# bump all others by default
ssl_bump server-first all
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)
# +------------------------------------------------------------------------------+
# | Endian Firewall |
# +------------------------------------------------------------------------------+
# | Copyright (c) 2005-2006 Endian |
# | Endian GmbH/Srl |
# | Bergweg 41 Via Monte |
# | 39057 Eppan/Appiano |
# | ITALIEN/ITALIA |
# | info@endian.it |
# | |
# | This program is free software; you can redistribute it and/or |
# | modify it under the terms of the GNU General Public License |
# | as published by the Free Software Foundation; either version 2 |
# | of the License, or (at your option) any later version. |
# | |
# | This program is distributed in the hope that it will be useful, |
# | but WITHOUT ANY WARRANTY; without even the implied warranty of |
# | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
# | GNU General Public License for more details. |
# | |
# | You should have received a copy of the GNU General Public License |
# | along with this program; if not, write to the Free Software |
# | Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. |
# | http://www.fsf.org/ |
# +------------------------------------------------------------------------------+
# START AUTHENTICATION
# windows logon name for auth
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --configfile=/etc/samba/winbind.conf
auth_param ntlm children 45
auth_param ntlm keep_alive off
# domain user or auth
auth_param basic program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic --configfile=/etc/samba/winbind.conf
auth_param basic children 45
auth_param basic realm geekzilla.geek
#kerberos
auth_param negotiate program /usr/lib/squid/negotiate_wrapper_auth --ntlm /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --configfile=/etc/samba/winbind.conf --kerberos /usr/lib/squid/negotiate_kerberos_auth
auth_param negotiate children 45
auth_param negotiate keep_alive off
icap_enable on
icap_service_revival_delay 30
icap_service_failure_limit -1
icap_preview_enable on
icap_preview_size 128
icap_send_client_ip on
icap_send_client_username on
