Squid 6.13 kan forwardproxyverzoeken via TLS accepteren als het met GnuTLS of OpenSSL is gebouwd. Dit beschermt de client-proxyverbinding zonder de afzonderlijke sessie van de HTTPS-bestemming te onderscheppen.

  1. Verkrijg een certificaat voor de hostnaam waarmee clients Squid benaderen. Beperk de privésleutel tot de service-identiteiten die hem nodig hebben.
  2. Voeg een TLS-listener toe met je toegewezen adres en de echte certificaatpaden:
https_port 192.0.2.10:3129 tls-cert=/etc/squid/proxy-chain.pem tls-key=/etc/squid/proxy-key.pem

Behoud de clienttoestaanlijst en bestemmingsbeperkingen en het authenticatiebeleid. De listener geeft geen toegang. Een bestaande http_port blijft ook actief; verwijder of beperk die oudere listener als alle clientverbindingen TLS moeten gebruiken. Er is geen accelerator-, onderscheppings- of certificaatgeneratiemodus nodig.

Laat de configuratie parseren voordat je de bedoelde dienst herlaadt. De parsercontrole valideert structuur en het laden van certificaten, geen netwerkbereikbaarheid. Stuur na succesvol herladen een verzoek via het TLS-endpoint vanaf een toegestane client:

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

Gebruik de echte proxyhostnaam en het goedgekeurde CA-bestand. Een publiek vertrouwd proxycertificaat heeft mogelijk geen eigen bundel nodig. --proxy-cacert stelt proxyvertrouwen in en houdt bestemmingsverificatie gescheiden; behoud beide controles.

Bekijk de werkelijke listener en certificaatnaam en test ook een bron onder je controle die geweigerd moet worden. Alleen succesvol parseren bevestigt geen clientvertrouwen of toegangsgrens.

Gerelateerde artikelen