Un listener TLS per forward proxy in Squid 6.13

Squid 6.13 può accettare richieste forward proxy su TLS se compilato con GnuTLS o OpenSSL. Questo protegge il collegamento client-proxy senza intercettare la sessione separata della destinazione HTTPS.

1. Ottieni un certificato per il nome host che i client useranno per raggiungere Squid. Limita l’accesso alla chiave privata alle identità di servizio che ne hanno bisogno.
2. Aggiungi un listener TLS con l’indirizzo assegnato e i percorsi reali dei certificati:

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

Mantieni la lista dei client ammessi e le restrizioni di destinazione, oltre alla politica di autenticazione. Il listener non concede accesso. Lascia anche attivo un eventuale http_port esistente: rimuovi o limita quel vecchio listener se tutte le connessioni client devono usare TLS. Non è richiesta alcuna modalità acceleratore, intercettazione o generazione dei certificati.

Analizza la configurazione prima di ricaricare il servizio previsto. Il controllo del parser verifica struttura e caricamento dei certificati, non la raggiungibilità di rete. Dopo una ricarica riuscita, invia una richiesta attraverso l’endpoint TLS da un client ammesso:

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

Usa il nome host reale del proxy e il file CA approvato. Un certificato proxy pubblicamente attendibile può non richiedere un bundle personalizzato. --proxy-cacert configura la fiducia del proxy e lascia separata la verifica della destinazione; mantieni entrambi i controlli.

Controlla il listener effettivo e il nome del certificato, poi prova anche una sorgente controllata che deve essere respinta. Il solo parsing riuscito non stabilisce la fiducia del client né il confine di accesso.