Squid e HTTPS

[Marcos Carraro]

Boa Tarde a todos, 

Hoje, configurei no debian o squid 3.0 para testes, pois o servidor que temos, é terceirizado ainda :/ 

Vamos ao que interessa, para configurar tranquilo, não tem problema, roda na maior santa paz, so que tem um porem, procurei no google, e em vários foruns e o pessoal falou que https não rola no transparent, e isso é verdade, se eu configurar o proxy manualmente no meu brosewar https rola na boa, agora se colocar transparent, https não anda.....

A maioria dos foruns, e buscas, o pessoal falou que tem que fazer, um nat da 443 para 3128 | aqui não rolou mandaram mascarar a 443 e não rolou....

Segue o squid.conf

####################

#   squid.conf     #

#    Versao 3      #

#   Since 2010     #

#    Debian :D     #

#  Marcos Carraro  #

####################

#==========================#

#  Configuracao de rede    #

#==========================#

#--Porta do squid

http_port 192.168.16.254:3128 transparent

http_port 127.0.0.1:3128 transparent

#==========================#

# Config Tamanho Cache     #

#==========================#

 hierarchy_stoplist cgi-bin ?

    acl QUERY urlpath_regex cgi-bin \?

    no_cache deny QUERY

#--Se for um servidor dedicado coloque 80% caso contrário a metada

cache_mem 200 MB

#--Define o valor maximo e minimo para troca de objetos armazenados, são expressados em % então quanto mais perto do 100% mais serão descartados para a entrada de novos.

cache_swap_low 94

cache_swap_high 98

#-- Diretorio cache do squid. aqui indicamos que /var/cachsquid é o local onde ficara os arquivos, com no máximo 20gb de tamanho dividido em 64 pastas e dentro delas podendo chegar a 256 subpastas.OBS:.cache_dir = 20GB -> 200MB de RAM usada

cache_dir diskd /var/sistema/squid/cache 20000 64 256

#Q1=64 Q2=720

#--Tamanho máxido dos arquivos a serem cacheados, qualquer arquivo maior, não sera salvo no disco.

maximum_object_size 102400 KB

maximum_object_size_in_memory 40 KB

ipcache_size 1024

#--Ips em cache percentual

ipcache_low 90

ipcache_high 95

# --Dominio complementares

fqdncache_size 1024

#--Repasar cache

cache_replacement_policy heap LFUDA

memory_replacement_policy heap GDSF

#==========================#

# Configuracao de logs     #

#==========================#

#--Log de sites visitados do squid

access_log /var/sistema/squid/log/access.log squid

cache_log /var/sistema/squid/log/cache.log

cache_store_log none

#--Ajuda a identificar problemas

pid_filename /var/sistema/squid/log/squid3.pid

#--Bloqueia aplicativos

mime_table /usr/share/squid3/mime.conf

cache_mgr webmaster

mail_program mail

#=============================#

# Configuracao Tuning cache   #

#=============================#

#--Isso faz com que o squid libere a memoria mais rapidamente

memory_pools off

#--Especifiac um disco executavel deixe padrão

diskd_program /usr/lib/squid3/diskd

unlinkd_program /usr/lib/squid3/unlinkd

#--Especifica quando procurar por novas atualizacoes dos sites em cache.

#-- 15minutos 20% 2280 dois dias

refresh_pattern ^ftp:           15    20%     2280

refresh_pattern ^gopher:        15    0%      2280

refresh_pattern (cgi-bin|\?)    0     0%      0

refresh_pattern .               15    20%     2280

#--Cache para abortamento do download

quick_abort_max 16 KB

quick_abort_pct 95

quick_abort_min 16 KB

#--Header das paginas da web

request_header_max_size 50 KB

reply_header_max_size 50 KB

request_body_max_size 0 KB

#==========================#

# TimeOut                 #

#==========================#

negative_ttl 0 minutes

positive_dns_ttl 6 hours

negative_dns_ttl 0 minutes

# forward_timeout 4 minutes

# connect_timeout 1 minute

# peer_connect_timeout 30 seconds

# read_timeout 15 minutes

# request_timeout 5 minutes

# persistent_request_timeout 1 minute

# client_lifetime 1 day

# half_closed_clients on

# pconn_timeout 120 seconds

# ident_timeout 10 seconds

# shutdown_lifetime 30 seconds

#==========================#

# Controle de acesso ACL   #

#==========================#

#--Configuração das ACLS

acl manager proto cache_object

acl localhost src 127.0.0.1/32

acl to_localhost dst 127.0.0.0/8

#--Nome da ACL de sua rede e o IP da mesma

acl redelocal src 192.168.16.0/24

#==========================#

# PORTAS DO SQUID          #

#==========================#

#--Portas da internet manter o padrao

acl SSL_ports port 443 444 563

acl Safe_ports port 80 443 444 563 1863      # http

acl Safe_ports port 443 563 1863    # https, snews

acl Safe_ports port 70          # gopher

acl Safe_ports port 210         # wais

acl Safe_ports port 1025-65535  # unregistered ports

acl Safe_ports port 280         # http-mgmt

acl Safe_ports port 488         # gss-http

acl Safe_ports port 591         # filemaker

acl Safe_ports port 777         # multiling http

acl CONNECT method CONNECT

http_access allow manager localhost

http_access deny manager

http_access deny !Safe_ports

http_access deny CONNECT !SSL_ports

#===========================#

# Autenticacao Usuarios     #

#===========================#

#--caminho que contem o arquivo com senha

#--Nao esqueca de criar o arquivo passwdsquid

#--Para adicionar os usuarios no squid

#-- htpasswd /var/sistema/squid/usuarios marcos

#auth_param basic program /usr/lib/squid3/ncsa_auth /var/sistema/squid/usuarios

#auth_param basic children 5

#--Tempo para permanecer com a sessao aberta

#auth_param basic credentialsttl 1 hour

#--Texto que ira aparecer na tela

#auth_param basic realm Digite seu Login e sua Senha.

#--Dessativa a diferenciação de maisuculas e minusculas

#auth_param basic casesensitive off

#===============================#

#  Liberacao de sites ou deny   #

#===============================#

#--Acl sites sem senha/ se for utilizar autenticacao de usuarios

#acl semsenha url_regex -i "/var/sistema/squid/acls/semsenha"

#--Para colocar squid com senha descomentar a linha abaixo

#==================#

# http_access      #

#==================#

#--libera o acesso para a sua rede mas bloqueia o resto que nao for liberado

http_access deny !redelocal

#--libera os sites que nao irao pedir senha

#http_access allow semsenha

#--Libera usuarios autenticados

#http_access allow squidcomsenha

#--Bloqueia os sites

http_access deny bloqueados

#=======================#

#  miscelanea           #

#=======================#

httpd_suppress_version_string off

#--Nome do proxy

visible_hostname power_proxy.rede.local

#--Local das paginas com erro

error_directory /var/sistema/squid/html/

Ele funciona perfeitamente, como eu falei so não abre qualquer site em https :/

--
att
Marcos Carraro
m a r q u i n h o s
Linux user #511627

[Gabriel Oliveira]

Eu como um programador metido a sys admin aprendi algumas coisinhas ultimamente que acho q podem lhe ser úteis.

No meu caso, configurei Apache + HTTPS para um servidor SVN poder ser acessado "da rede externa". Fora toda a criação de certificados e apache.conf e etc, tive que configurar meu modem E o roteador (que não estão em NAT) para aceitarem conexões HTTPS na porta 44300 (porta chutada), dado que a 443, mesmo estando aberta em ambos os locais citados, não funcionava....

A explicação que achei (não que ela tenha me agradado, but...) foi que portas abaixo de 1k são bloqueadas pelo Sisop. A idéia que eu te dou é tentar configurar esses dois individuos corretamente e mandar o squid escutar na 3128 da vida ae....

Manda teu modelo de router/modem que talvez consiga te ajudar melhor...

Como leigo, olhei teu squid.conf e detectei uma linha "acl SSL_ports" que ta apontada pra esperar tráfego https na porta 443. Não teria que mudar pra escutar  na 3128 ??

--

Gabriel Oliveira
Computer Science - UFRGS - Brazil

--
Mensagem enviada para <http://groups.google.com/group/tchelinux>.

[Vinicius Mello]

Marcos Carraro wrote:
> Boa Tarde a todos,
>
> isso � verdade, se eu configurar o proxy manualmente no

> meu brosewar https rola na boa, agora se colocar

> transparent, https n�o anda.....

>
> A maioria dos foruns, e buscas, o pessoal falou que tem

> que fazer, um nat da 443 para 3128 | aqui n�o rolou
> mandaram mascarar a 443 e n�o rolou....

Ol� Marcos,

N�o vai funcionar redirecionar a porta 443/tcp pra 3128/tcp.

Quando o navegador conecta ele est� esperando iniciar uma
negocia��o SSL, e a porta 3128 � uma porta de proxy (sem SSL).

Configurando manualmente o proxy funciona porque o navegador
sabe que est� conectando em um proxy e usa o m�todo CONNECT
pra iniciar a sess�o SSL e o proxy apenas envia e recebe os
pacotes (sem participar da negocia��o).

Pra resolver o problema eu lembro de duas alternativas:

1) configurar automaticamente o proxy dos clientes com WPAD
http://www.vivaolinux.com.br/artigo/Configuracao-automatica-(mesmo)-de-proxy-com-WPAD

2) liberar no firewall os clientes pra conectarem na porta
443/tcp de qualquer m�quina externa

Sds,
vmm.

[Eduardo Sachs]

Eu sempre utilizo o WPAD e nunca tive problemas, acho que é a melhor opção para maior transparencia para o browser.

Em 16 de dezembro de 2010 16:24, Vinicius Mello <vmm...@vmmello.eti.br> escreveu:

Marcos Carraro wrote:

Boa Tarde a todos,

isso é verdade, se eu configurar o proxy manualmente no

meu brosewar https rola na boa, agora se colocar

transparent, https não anda.....

A maioria dos foruns, e buscas, o pessoal falou que tem

que fazer, um nat da 443 para 3128 | aqui não rolou
mandaram mascarar a 443 e não rolou....

Olá Marcos,

Não vai funcionar redirecionar a porta 443/tcp pra 3128/tcp.

Quando o navegador conecta ele está esperando iniciar uma
negociação SSL, e a porta 3128 é uma porta de proxy (sem SSL).

Configurando manualmente o proxy funciona porque o navegador

sabe que está conectando em um proxy e usa o método CONNECT
pra iniciar a sessão SSL e o proxy apenas envia e recebe os
pacotes (sem participar da negociação).

Pra resolver o problema eu lembro de duas alternativas:

1) configurar automaticamente o proxy dos clientes com WPAD
http://www.vivaolinux.com.br/artigo/Configuracao-automatica-(mesmo)-de-proxy-com-WPAD


2) liberar no firewall os clientes pra conectarem na porta

443/tcp de qualquer máquina externa



Sds,
vmm.

--
Mensagem enviada para <http://groups.google.com/group/tchelinux>.

--
Att,

Eduardo Sachs - www.eduardosachs.org
LPIC-1 Junior Level Linux Professional
LPIC-2 Advanced Level Linux Professional
Novell Certified Linux Administrator 11
Novell Data Center Technical Specialist

[Marcos Carraro]

Boa Tarde @gabriel não cara, 3128 é a porta do squid mesmo, nas configurações de ACLS Safe Port, são as portas "seguras" do squid, de serviços que podemos acessar, do tipo, porta http é 80, mas se o teu site na nuvem ta escutando na porta 90 teria que setar ali também 80 90 e assim, vai, no final, são portas de serviços.....

www.marquinhos.co.cc
Linux user #511627

[Marcos Carraro]

Humm, Irei testar, tinha lido isso no guia do hardware se não estou enganado, mas vou dar um jeito de fazer rolar, o https :D

assim que possível irei postar aqui mais informações..

Abraços

Em 16 de dezembro de 2010 16:24, Vinicius Mello <vmm...@vmmello.eti.br> escreveu:

Marcos Carraro wrote:

Boa Tarde a todos,

isso é verdade, se eu configurar o proxy manualmente no

meu brosewar https rola na boa, agora se colocar

transparent, https não anda.....

A maioria dos foruns, e buscas, o pessoal falou que tem

que fazer, um nat da 443 para 3128 | aqui não rolou
mandaram mascarar a 443 e não rolou....

Olá Marcos,

Não vai funcionar redirecionar a porta 443/tcp pra 3128/tcp.

Quando o navegador conecta ele está esperando iniciar uma

negociação SSL, e a porta 3128 é uma porta de proxy (sem SSL).

Configurando manualmente o proxy funciona porque o navegador

sabe que está conectando em um proxy e usa o método CONNECT

pra iniciar a sessão SSL e o proxy apenas envia e recebe os
pacotes (sem participar da negociação).

Pra resolver o problema eu lembro de duas alternativas:

1) configurar automaticamente o proxy dos clientes com WPAD
http://www.vivaolinux.com.br/artigo/Configuracao-automatica-(mesmo)-de-proxy-com-WPAD


2) liberar no firewall os clientes pra conectarem na porta

443/tcp de qualquer máquina externa



Sds,
vmm.

--
Mensagem enviada para <http://groups.google.com/group/tchelinux>.

--
att
Marcos Carraro
m a r q u i n h o s

www.marquinhos.co.cc
Linux user #511627

[Elgio Schlemer]

Reafirmo o que o Vinícius disse: proxy transparente não funciona para HTTPS

1 - ou se configura os navegadores,
2- ou se usa WPAD,
3 -ou se usa NAT para HTTPS

Lembrando que na última solução os clientes precisam resolver nomes, ou seja, deve-se ter um DNS válido.
(como já deve ter para o caso de proxy transparente)

WPAD pode ser configurado por DNS ou por DHCP.

Por experiência própria: configure das duas maneiras

[Marcos Carraro]

Boa Noite, @elgio

Sim, procurei e procurei, troquei uma idéia com o pessoal aqui das redondezas e me falaram que realmente HTTPS não rola no squid transparente, e que a  solução mais implementada é o nat para https "443" no caso.

Irei configurar meu firewall dessa maneira, e outra terei de configurar o bind ou djbdns para resolver os dominios.

Abraços, obrigado pelas dicas.

[Eduardo Sachs]

Marcos,

Se você for configurar nat para HTTPS como fica o filtro de URLs para os sites indeviduos em HTTPS? Fazer através do iptables? fica um inferno...

Eu recomendo 100% você utilizar o WPAD. A configuração é simples e você tem o proxy para HTTP e HTTPS.

[Marcos Carraro]

Olha, ao menos rola o bloqueio por palavras, e dominio, o que me relataram, ao menos não testei, no trampo, temos nat https, e orkut bloqueado sem maiores problemas.

Linux user #511627

[Elgio Schlemer]

Não, não rola.

Por HTTPS via Nat tu só consegue bloquear via iptables pelo IP. E de uma forma muito limitada: quantos sites do Brasil usam, por exemplo, os Ips da LocaWeb?

Por Proxy não transparente (mesmo que por WPAD) tu podes bloquear apenas palavras na URL de uma requisição HTTPS.

[Eduardo Sachs]

Tudo bem.

Mas fazer isso com iptables é uma naba... proxy sempre será mais eficiente para fazer politicas de navegação em HTTPS ou HTTP.

[Ricardo Arnoud]

Bloqueia tudo no firewall na porta 443, e libera conforme forem te pedindo.. geralmente é site de banco que precisa liberar e algum site do governo e deu.. eh bem tranquilo, ai jah bloqueia o ultrasurf com isso.


Ricardo Arnoud

2010/12/18 Marcos Carraro <marco...@gmail.com>

--
Thanks,
Ricardo Arnoud

[Marcos Carraro]

Bom Dia, 

Sim, mas essa é a idéia, IPTABLES para fazer o nat da 443.

Squid, squidguard, bloqueio de palavras, e domínios, então mesmo se o site for https, ele sera bloqueado correto ou errado?

[Vinicius Mello]

On 12/20/2010 09:48 AM, Marcos Carraro wrote:
> Bom Dia,
>
> Squid, squidguard, bloqueio de palavras, e dom�nios, ent�o mesmo se o

> site for https, ele sera bloqueado correto ou errado?

Bom dia Marcos,

A resposta �: errado.

Pra explicar de uma forma compreens�vel precisaria de umas 4 p�ginas de
texto, mas vou tentar fazer em meia p�gina.

O squid n�o vai bloquear conte�do (urls, palavras, etc) em uma conex�o
SSL porque ele n�o tem acesso as chaves sim�tricas da sess�o pra
inspecionar o conte�do.

Quando o cliente conecta no proxy pra uma conex�o SSL, envia uma
requisi��o do tipo:

CONNECT www.site.com:443

E a partir da� o squid s� conecta na porta do host e envia/recebe os
dados, sem inspecion�-los.

Ele s� consegue bloquear o hostname/dom�nio e a porta, seria como dizer:
- facebook.com, porta 443: bloqueado
- gmail.com, porta 443: permitido

Na sintaxe do squid:

acl ssl_bloqueado dstdomain .facebook.com
acl ssl_bloqueado dstdomain .orkut.com

http_access deny ssl_bloqueado CONNECT

N�o � muito diferente do que tentar bloquear por iptables (j� que � uma
quest�o de host-porta), mas tem a conveni�ncia de que se consegue fazer
um bloqueio din�mico por hostname-porta.

Sds,
vmm.

[Elgio Schlemer]

Oi Vinicius,

Eu acrescentaria:

Em 20-12-2010 10:50, Vinicius Mello escreveu:
> N�o � muito diferente do que tentar bloquear por iptables (j� que �
> uma quest�o de host-porta), mas tem a conveni�ncia de que se consegue
> fazer um bloqueio din�mico por hostname-porta.
>

Sim, � muito diferente.

Por iptables tens que bloquear o IP. Muitas URL podem compartilhar o
mesmo n�mero IP (exemplo dos provedores terra, locaweb, etc) ao passo
que uma �nica URL pode ter v�rios Ips.

Vivia isto no meu dia a dia tentando bloquear orkut HTTPS sem bloquear
google e gmail via iptables (uma PENIT�NCIA)

S� consegui realmente me libertar deste dilema quando implantei wpad
(onde o bloquei poir URL funciona mesmo para HTTPS, como explicaste)

[]'s

[Eduardo Sachs]

Concordo com o Elgio, pois tive a mesma experiencia.

Em 20 de dezembro de 2010 11:27, Elgio Schlemer <elg...@gmail.com> escreveu:

Oi Vinicius,

Eu acrescentaria:

Em 20-12-2010 10:50, Vinicius Mello escreveu:

> Não é muito diferente do que tentar bloquear por iptables (já que é
> uma questão de host-porta), mas tem a conveniência de que se consegue
> fazer um bloqueio dinâmico por hostname-porta.
>

Sim, é muito diferente.

Por iptables tens que bloquear o IP. Muitas URL podem compartilhar o

mesmo número IP (exemplo dos provedores terra, locaweb, etc) ao passo
que uma única URL pode ter vários Ips.

Vivia isto no meu dia a dia tentando bloquear orkut HTTPS sem  bloquear

google e gmail via iptables (uma PENITÊNCIA)

Só consegui realmente me libertar deste dilema quando implantei wpad

(onde o bloquei poir URL funciona mesmo para HTTPS, como explicaste)

[]'s

--
Mensagem enviada para <http://groups.google.com/group/tchelinux>.

[Vinicius Mello]

E a� �lgio,

On 12/20/2010 11:27 AM, Elgio Schlemer wrote:
> Oi Vinicius,
>
> Eu acrescentaria:
>
> Em 20-12-2010 10:50, Vinicius Mello escreveu:
>> N�o � muito diferente do que tentar bloquear por iptables (j� que �
>> uma quest�o de host-porta), mas tem a conveni�ncia de que se consegue
>> fazer um bloqueio din�mico por hostname-porta.
>>
>
> Sim, � muito diferente.

Pode ser. Eu estava pensando no detalhe que, j� que estamos falando de
SSL, a cada par IP-porta est� associado um certificado, e mesmo em
hospedagem compartilhada os sites n�o compartilham a porta 443 (cada
virtualhost precisa de um IP exclusivo pra ter SSL).

> S� consegui realmente me libertar deste dilema quando implantei wpad
> (onde o bloquei poir URL funciona mesmo para HTTPS, como explicaste)

O bloqueio n�o � exatamente por "URL", � por hostname, certo?

Abra�o,
vmm.

[Marcos Carraro]

Boa Tarde a todos, 

Após um bom almoço, pensei e repensei, e estudei, e procurei, analisei, e agora passei a concordar com todos, irei configurar o WPAD.

Obrigado a todos, que ajudarão, nesse problema, fica a dica, para todos, penso que com isso, iremos ganhar performance, pois não terá de processar várias, para ler as regras iptables, squid, então fica novamente o meu muito obrigado a todos.

So uma pergunta bem distante desse problema.

Seu Elgio, como você fez aquela mensagem criptografada de feliz natal a todos, com o comando dc -e??

Obrigado novamente.

Em 20 de dezembro de 2010 11:55, Vinicius Mello <vmm...@vmmello.eti.br> escreveu:

E aí Élgio,

On 12/20/2010 11:27 AM, Elgio Schlemer wrote:

Oi Vinicius,

Eu acrescentaria:

Em 20-12-2010 10:50, Vinicius Mello escreveu:

Não é muito diferente do que tentar bloquear por iptables (já que é
uma questão de host-porta), mas tem a conveniência de que se consegue
fazer um bloqueio dinâmico por hostname-porta.

Sim, é muito diferente.

Pode ser. Eu estava pensando no detalhe que, já que estamos falando de SSL, a cada par IP-porta está associado um certificado, e mesmo em hospedagem compartilhada os sites não compartilham a porta 443 (cada virtualhost precisa de um IP exclusivo pra ter SSL).

Só consegui realmente me libertar deste dilema quando implantei wpad

(onde o bloquei poir URL funciona mesmo para HTTPS, como explicaste)

O bloqueio não é exatamente por "URL", é por hostname, certo?


Abraço,

vmm.

--
Mensagem enviada para <http://groups.google.com/group/tchelinux>.

--
att
Marcos Carraro
Linux user #511627

[Elgio Schlemer]

Em 20-12-2010 13:37, Marcos Carraro escreveu:
> Seu Elgio, como voc� fez aquela mensagem criptografada de feliz natal

> a todos, com o comando dc -e??

Mist�rio...

Ora dessas eu ensino. N�o � m� vontade agora, � falta de tempo mesmo.

DICA:
dc -e "65P 83P 67P 73P 73P 10P"

[Marcos Carraro]

Blz, so queria saber se era pelo comando dc mesmo, achei que fosse por outro comando e utilizasse o dc -e somente para descriptografar.

Abraços

Em 20 de dezembro de 2010 13:42, Elgio Schlemer <elg...@gmail.com> escreveu:

Em 20-12-2010 13:37, Marcos Carraro escreveu:

> Seu Elgio, como você fez aquela mensagem criptografada de feliz natal

> a todos, com o comando dc -e??

Mistério...

Ora dessas eu ensino. Não é má vontade agora, é falta de tempo mesmo.

DICA:
dc -e "65P 83P 67P 73P 73P 10P"

--
Mensagem enviada para <http://groups.google.com/group/tchelinux>.