TLS forward-proxy listener sa Squid 6.13

Kayang tumanggap ng Squid 6.13 ng forward-proxy request sa TLS kapag binuo ito gamit ang GnuTLS o OpenSSL. Pinoprotektahan nito ang client–proxy link nang hindi ini-intercept ang hiwalay na session ng HTTPS na destinasyon.

1. Kumuha ng certificate para sa hostname na gagamitin ng mga client sa pag-abot sa Squid. Limitahan ang private key sa mga service identity na nangangailangan nito.
2. Magdagdag ng TLS listener gamit ang nakatalagang address at totoong path ng certificate:

https_port 192.0.2.10:3129 tls-cert=/etc/squid/proxy-chain.pem tls-key=/etc/squid/proxy-key.pem

Panatilihin ang client allowlist at mga limitasyon sa destinasyon pati ang authentication policy. Hindi nagbibigay ng access ang listener. Nananatiling aktibo rin ang dati nang http_port; alisin o limitahan ang mas lumang listener kung kailangang TLS ang lahat ng client connection. Hindi kailangan ng accelerator, interception, o certificate-generation mode.

I-parse ang configuration bago i-reload ang nilalayong serbisyo. Pinapatunayan ng parser check ang istruktura at pag-load ng certificate, hindi ang network reachability. Pagkatapos ng matagumpay na reload, mag-request sa TLS endpoint mula sa pinapayagang client:

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

Gamitin ang totoong proxy hostname at aprubadong CA file. Maaaring hindi na kailangan ng custom bundle ang publicly trusted na proxy certificate. Itinatakda ng --proxy-cacert ang proxy trust at iniiwang hiwalay ang destination verification; panatilihin ang parehong pagsusuri.

Suriin ang aktuwal na listener at pangalan ng certificate, saka subukan din ang kontroladong source na dapat tanggihan. Hindi sapat ang matagumpay na pag-parse para mapatunayan ang tiwala ng client o ang hangganan ng access.