Squid 6.13 puede aceptar peticiones de proxy de salida sobre TLS si está compilado con GnuTLS u OpenSSL. Esto protege el enlace cliente–proxy sin interceptar la sesión independiente del destino HTTPS.

  1. Obtén un certificado para el nombre de host que usarán los clientes para llegar a Squid. Limita la clave privada a las identidades de servicio que la necesitan.
  2. Añade un punto de escucha TLS con la dirección asignada y las rutas reales de los certificados:
https_port 192.0.2.10:3129 tls-cert=/etc/squid/proxy-chain.pem tls-key=/etc/squid/proxy-key.pem

Conserva la lista de clientes permitidos y las restricciones de destino, además de la política de autenticación. El punto de escucha no concede acceso. También deja activo un http_port existente; elimina o restringe ese punto anterior si todas las conexiones de clientes deben usar TLS. No hace falta ningún modo acelerador, de interceptación o de generación de certificados.

Analiza la configuración antes de recargar el servicio previsto. La comprobación del analizador valida la estructura y la carga de certificados, no la accesibilidad de red. Tras recargar correctamente, envía una petición por el 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 el nombre real del proxy y el archivo CA aprobado. Un certificado de proxy de confianza pública puede no necesitar un paquete personalizado. --proxy-cacert configura la confianza del proxy y deja separada la verificación del destino; conserva ambas comprobaciones.

Inspecciona el punto de escucha real y el nombre del certificado; prueba también un origen controlado que deba ser rechazado. Un análisis correcto por sí solo no establece la confianza del cliente ni el límite de acceso.

Artículos relacionados