Squid 6.13 pode aceptar peticións de proxy de saída sobre TLS se está compilado con GnuTLS ou OpenSSL. Isto protexe a ligazón cliente–proxy sen interceptar a sesión independente do destino HTTPS.

  1. Obtén un certificado para o nome de host que usarán os clientes para chegar a Squid. Limita a clave privada ás identidades de servizo que a precisan.
  2. Engade un punto de escoita TLS co enderezo asignado e as rutas reais dos certificados:
https_port 192.0.2.10:3129 tls-cert=/etc/squid/proxy-chain.pem tls-key=/etc/squid/proxy-key.pem

Conserva a lista de clientes permitidos e as restricións de destino, ademais da política de autenticación. O punto de escoita non concede acceso. Tamén deixa activo un http_port existente; elimina ou restrinxe ese punto anterior se todas as conexións dos clientes deben usar TLS. Non se precisa modo acelerador, de interceptación nin de xeración de certificados.

Analiza a configuración antes de recargar o servizo previsto. A comprobación do analizador valida a estrutura e a carga dos certificados, non a accesibilidade de rede. Tras unha recarga correcta, envía unha petición polo punto de conexión TLS desde un cliente permitido:

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

Usa o nome real do proxy e o ficheiro CA aprobado. Un certificado de proxy de confianza pública pode non precisar un paquete personalizado. --proxy-cacert configura a confianza do proxy e deixa separada a verificación do destino; conserva ambas as comprobacións.

Inspecciona o punto de escoita real e o nome do certificado, e proba tamén unha orixe controlada que deba ser rexeitada. Unha análise correcta por si soa non establece a confianza do cliente nin o límite de acceso.

Artigos relacionados