TLS-plusendprokurila aŭskultilo en Squid 6.13
Aldonu TLS-plusendprokurilan aŭskultilon en Squid 6.13 sen interkapti la HTTPS-seancon de la celo.
Squid 6.13 povas akcepti plusendprokurilajn petojn per TLS kiam ĝi estas konstruita kun GnuTLS aŭ OpenSSL. Tio protektas la ligon kliento–prokurilo sen interkapti la apartan seancon de la HTTPS-celo.
- Akiru atestilon por la gastignomo per kiu klientoj atingos Squid. Limigu la privatan ŝlosilon al la servaj identecoj kiuj ĝin bezonas.
- Aldonu TLS-aŭskultilon kun via asignita adreso kaj veraj atestilaj vojoj:
https_port 192.0.2.10:3129 tls-cert=/etc/squid/proxy-chain.pem tls-key=/etc/squid/proxy-key.pemKonservu la permesliston de klientoj kaj cellimigojn kaj la aŭtentikigan politikon. La aŭskultilo ne donas aliron. Ĝi ankaŭ lasas ekzistantan http_port aktiva; forigu aŭ limigu tiun pli malnovan aŭskultilon se ĉiuj klientaj konektoj devas uzi TLS. Neniu akcelila, interkapta aŭ atestil-genera reĝimo necesas.
Analizu la agordon antaŭ reŝargi la celitan servon. La analiza kontrolo validigas strukturon kaj ŝargadon de atestiloj, ne retan atingeblon. Post sukcesa reŝargo, faru peton tra la TLS-finpunkto de permesita kliento:
curl --proxy https://proxy.example:3129 --proxy-cacert approved-proxy-ca.pem --connect-timeout 5 --max-time 15 https://example.com/Uzu la veran prokurilan gastignomon kaj aprobitan CA-dosieron. Publike fidata prokurila atestilo eble ne bezonas propran pakon. --proxy-cacert agordas prokurilan fidon kaj lasas celkontrolon aparta; konservu ambaŭ kontrolojn.
Inspektu la veran aŭskultilon kaj atestilan nomon, poste testu ankaŭ regatan fonton kiu devas esti rifuzita. Sukcesa analizo sola ne konfirmas klientan fidon aŭ la alirlimon.