In TLS-forwardproxylistener yn Squid 6.13

Foegje in TLS-forwardproxylistener ta yn Squid 6.13 sûnder de HTTPS-sesje fan it doel te ûnderskeppen.

Squid 6.13 kin forwardproxyfersiken oer TLS oannimme as it mei GnuTLS of OpenSSL boud is. Dat beskermet de kliïnt-proxyferbining sûnder de aparte sesje fan it HTTPS-doel te ûnderskeppen.

  1. Krij in sertifikaat foar de hostnamme dêr’t kliïnten Squid mei berikke. Behein de priveekaai ta de tsjinstidentiteiten dy't him nedich hawwe.
  2. Foegje in TLS-listener ta mei dyn tawiisde adres en de echte sertifikaatpaden:
https_port 192.0.2.10:3129 tls-cert=/etc/squid/proxy-chain.pem tls-key=/etc/squid/proxy-key.pem

Behâld de tastiene kliïntlist en doelbeheiningen en it autentikaasjebelied. De listener jout gjin tagong. In besteande http_port bliuwt ek aktyf; helje dy âldere listener fuort of behein him as alle kliïntferbiningen TLS brûke moatte. Gjin accelerator-, ûnderskeppings- of sertifikaatgeneraasjemodus is nedich.

Lit de konfiguraasje parsearje foardatst de bedoelde tsjinst opnij laadst. De parserkontrôle befêstiget struktuer en sertifikaatladen, net netwurkberikberens. Stjoer nei slagge opnij laden in fersyk troch it TLS-einpunt fan in tastiene kliïnt:

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

Brûk de echte proxyhostnamme en it goedkarde CA-bestân. In iepenbier fertroud proxysertifikaat hat mooglik gjin eigen bondel nedich. --proxy-cacert stelt proxyfertrouwen yn en hâldt doelferifikaasje apart; behâld beide kontrôles.

Besjoch de echte listener en sertifikaatnamme en test ek in boarne ûnder dyn kontrôle dy't wegere wurde moat. Allinnich slagge parsearjen befêstiget gjin kliïntfertrouwen of tagongsgrins.

Relatearre artikelen