Como criptografar a conexão com um servidor proxy do squid

Question

Eu configurei um servidor proxy anônimo do squid, e ele funciona completamente bem, mas não encontrei nada sobre como criptografar o tráfego entre mim e o próprio servidor. Por onde começar?

    

Answer 1

Estou digitando aqui o comando exato que agora uso para configurar uma criptografia de 2048 bits para o servidor proxy:

ssh -C2qTnN -D 8080 user@remote-address

enquanto as configurações de proxy do seu navegador (a mesma janela feia que aparece para as configurações do IE) devem apontar para 127.0.0.1:8080 para o campo SOCKS, todas as outras deixadas em branco (como normalmente falando sobre um proxy SOCKS)

Obviamente, todas as outras portas podem funcionar se abertas no servidor remoto.

    

Answer 2

A documentação do Squid faz referência a isso: link

No entanto, o problema provavelmente não é configurar o Squid, mas sim encontrar um navegador que funcione corretamente ...

O Google Chrome suporta uma conexão de proxy HTTPS, mas apenas por meio de um arquivo PAC de configuração automática ou pela opção de linha de comando --proxy-server (consulte link )

O Firefox ainda está "trabalhando", veja o link (7 anos e contando ). finalmente suporta isso a partir da versão 33, (graças a Dan pela atualização).

A execução de um local (na mesma máquina que o navegador) stunnel como um wrapper de proxy resolveria isso para qualquer navegador, mas pode não ser adequado à sua implantação pretendida. Esta página útil mostra como criar essa configuração (com autenticação PAM opcional):

link

Observe que isso é completamente diferente de usar stunnel para encapsular por meio de um proxy HTTP via CONNECT, esse é o cenário mais comumente documentado. Sua solução usando SOCKS via SSH é aproximadamente equivalente em alguns sentidos, mas você não tem suporte a HTTP, é irrestrito (pense em CONECTAR a qualquer porta), não tem armazenamento em cache e a autenticação não é gerenciada pelo navegador. / p>

Se você estiver usando a autenticação de proxy e desejar proteger os cabeçalhos de credenciais, isso (conexão de cliente-proxy HTTPS) é um bom plano. Caso contrário, essa configuração pode não resolver todos os problemas que se espera, e as conexões HTTPS tornam-se duplamente criptografadas, o que (pelo menos) aumenta ainda mais a latência de conexão.

1. você está se conectando a um site HTTP: o tráfego não criptografado deixa o proxy de qualquer maneira
2. você está se conectando a um site HTTPS: não há nada no proxy cliente que realmente precise ser criptografado, exceto o destino das solicitações CONNECT (ou seja, nome do host do site), mas o cliente TLS hello provavelmente terá um SNI contendo esse nome. e o servidor hello certamente terá um certificado do servidor, qualquer um dos quais pode ser interceptado

Outro caso em que agregaria valor é usar certificados de cliente para autenticação de proxy (mas os navegadores não suportam isso) , isso é relatado como trabalhando no Firefox (veja bug 209312 ).

Esta questão foi recentemente sinalizada pela CERT: Nota de vulnerabilidade VU # 905344 As mensagens HTTP CONNECT e 407 Proxy Authentication Required não são protegidas por integridade como resultado do ataque FalseCONNECT MITM.