Un point d’écoute de proxy TLS dans Squid 6.13
Ajoutez un point d’écoute de proxy direct avec TLS dans Squid 6.13, sans intercepter la session HTTPS de destination.
Compilé avec GnuTLS ou OpenSSL, Squid 6.13 peut accepter les requêtes de proxy direct sur TLS. Cela protège le lien client-proxy sans intercepter la session distincte de la destination HTTPS.
- Obtenez un certificat pour le nom d’hôte qu’utiliseront les clients pour joindre Squid. Limitez l’accès à sa clé privée aux identités de service qui en ont besoin.
- Ajoutez un point d’écoute TLS avec l’adresse qui vous est attribuée et les véritables chemins des certificats :
https_port 192.0.2.10:3129 tls-cert=/etc/squid/proxy-chain.pem tls-key=/etc/squid/proxy-key.pemConservez la liste des clients autorisés et les restrictions de destination, ainsi que la politique d’authentification. Le point d’écoute n’accorde aucun accès. Un http_port existant reste également actif ; supprimez ou limitez cette ancienne écoute si toutes les connexions clientes doivent utiliser TLS. Aucun mode accélérateur, interception ou génération de certificats n’est requis.
Analysez la configuration avant de recharger le service voulu. Le contrôle par l’analyseur valide la structure et le chargement des certificats, pas l’accessibilité réseau. Après un rechargement réussi, envoyez une requête via le point de connexion TLS depuis un client autorisé :
curl --proxy https://proxy.example:3129 --proxy-cacert approved-proxy-ca.pem --connect-timeout 5 --max-time 15 https://example.com/Utilisez le véritable nom d’hôte du proxy et le fichier CA approuvé. Un certificat de proxy reconnu publiquement peut ne pas nécessiter de bundle personnalisé. --proxy-cacert configure la confiance du proxy et laisse la vérification de destination séparée ; conservez les deux contrôles.
Inspectez l’écoute réelle et le nom du certificat, puis testez aussi une source contrôlée qui doit être refusée. Une analyse réussie ne suffit pas à établir la confiance du client ni la limite d’accès.