Squid 6.13 poate accepta cereri forward proxy prin TLS când este compilat cu GnuTLS sau OpenSSL. Asta protejează legătura client–proxy fără a intercepta sesiunea separată a destinației HTTPS.

  1. Obține un certificat pentru numele de gazdă pe care clienții îl vor folosi ca să ajungă la Squid. Limitează cheia privată la identitățile de serviciu care au nevoie de ea.
  2. Adaugă un listener TLS cu adresa atribuită și căile reale ale certificatelor:
https_port 192.0.2.10:3129 tls-cert=/etc/squid/proxy-chain.pem tls-key=/etc/squid/proxy-key.pem

Păstrează lista de clienți permiși și restricțiile de destinație, precum și politica de autentificare. Listenerul nu acordă acces. De asemenea, lasă activ un http_port existent; elimină sau restricționează listenerul vechi dacă toate conexiunile clienților trebuie să folosească TLS. Nu este nevoie de mod accelerator, interceptare sau generare de certificate.

Analizează configurația înainte de reîncărcarea serviciului dorit. Verificarea parserului validează structura și încărcarea certificatelor, nu accesibilitatea în rețea. După o reîncărcare reușită, trimite o cerere prin endpointul TLS de la un client permis:

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

Folosește numele real al proxy-ului și fișierul CA aprobat. Un certificat proxy cu încredere publică poate să nu aibă nevoie de un pachet personalizat. --proxy-cacert configurează încrederea în proxy și lasă verificarea destinației separată; păstrează ambele verificări.

Inspectează listenerul real și numele certificatului, apoi testează și o sursă controlată care trebuie respinsă. Analizarea reușită singură nu stabilește încrederea clientului sau limita de acces.

Articole similare