Squid 6.13 może przyjmować żądania forward proxy przez TLS, jeśli został zbudowany z GnuTLS lub OpenSSL. Chroni to łącze klient–proxy bez przechwytywania osobnej sesji celu HTTPS.

  1. Uzyskaj certyfikat dla nazwy hosta używanej przez klientów do dostępu do Squid. Ogranicz klucz prywatny do tożsamości usług, które go potrzebują.
  2. Dodaj nasłuch TLS z przydzielonym adresem i rzeczywistymi ścieżkami certyfikatów:
https_port 192.0.2.10:3129 tls-cert=/etc/squid/proxy-chain.pem tls-key=/etc/squid/proxy-key.pem

Zachowaj listę dozwolonych klientów i ograniczenia celów oraz politykę uwierzytelniania. Nasłuch nie przyznaje dostępu. Pozostawia też aktywny istniejący http_port; usuń lub ogranicz starszy nasłuch, jeśli wszystkie połączenia klientów muszą używać TLS. Nie potrzeba trybu akceleratora, przechwytywania ani generowania certyfikatów.

Sprawdź konfigurację parserem przed przeładowaniem właściwej usługi. Kontrola parsera sprawdza strukturę i ładowanie certyfikatów, a nie osiągalność sieciową. Po udanym przeładowaniu wykonaj żądanie przez punkt końcowy TLS z dozwolonego klienta:

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

Użyj rzeczywistej nazwy hosta proxy i zatwierdzonego pliku CA. Publicznie zaufany certyfikat proxy może nie wymagać własnego pakietu. --proxy-cacert konfiguruje zaufanie do proxy i pozostawia weryfikację celu osobno; zachowaj obie kontrole.

Sprawdź rzeczywisty nasłuch i nazwę certyfikatu, a potem przetestuj także kontrolowane źródło, które ma być odrzucone. Samo udane parsowanie nie potwierdza zaufania klienta ani granicy dostępu.

Powiązane artykuły