Um listener TLS de proxy de saída no Squid 6.13

O Squid 6.13 pode aceitar requisições de proxy de saída por TLS quando compilado com GnuTLS ou OpenSSL. Isso protege o enlace cliente–proxy sem interceptar a sessão separada do destino HTTPS.

1. Obtenha um certificado para o nome de host que os clientes usarão para chegar ao Squid. Restrinja a chave privada às identidades de serviço que precisam dela.
2. Adicione um listener TLS com o endereço atribuído a você e os caminhos reais dos certificados:

https_port 192.0.2.10:3129 tls-cert=/etc/squid/proxy-chain.pem tls-key=/etc/squid/proxy-key.pem

Mantenha a lista de clientes permitidos e as restrições de destino, além da política de autenticação. O listener não concede acesso. Ele também deixa ativo um http_port existente; remova ou restrinja esse listener anterior se todas as conexões de clientes tiverem que usar TLS. Não é necessário nenhum modo de aceleração, interceptação ou geração de certificados.

Analise a configuração antes de recarregar o serviço pretendido. A verificação do analisador valida a estrutura e o carregamento de certificados, não a acessibilidade de rede. Após uma recarga bem-sucedida, faça uma requisição pelo endpoint TLS a partir de um cliente permitido:

curl --proxy https://proxy.example:3129 --proxy-cacert approved-proxy-ca.pem --connect-timeout 5 --max-time 15 https://example.com/

Use o nome de host real do proxy e o arquivo CA aprovado. Um certificado de proxy publicamente confiável pode dispensar um pacote personalizado. --proxy-cacert configura a confiança do proxy e mantém a verificação do destino separada; preserve as duas verificações.

Inspecione o listener real e o nome do certificado e teste também uma origem controlada que deva ser negada. A análise bem-sucedida sozinha não comprova a confiança do cliente nem o limite de acesso.