TLS-вузел прамога проксі ў Squid 6.13

Squid 6.13 можа прымаць запыты прамога проксі праз TLS, калі сабраны з GnuTLS або OpenSSL. Гэта абараняе канал кліент–проксі без перахопу асобнага сеанса HTTPS-мэты.

1. Атрымайце сертыфікат для імя хоста, па якім кліенты будуць звяртацца да Squid. Абмяжуйце прыватны ключ службовымі ідэнтычнасцямі, якім ён патрэбны.
2. Дадайце TLS-вузел праслухоўвання з вылучаным адрасам і сапраўднымі шляхамі сертыфікатаў:

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

Захавайце спіс дазволеных кліентаў і абмежаванні мэтаў ды палітыку аўтэнтыфікацыі. Вузел праслухоўвання не дае доступу. Існы http_port таксама застаецца актыўным; выдаліце або абмяжуйце стары вузел, калі ўсе кліенцкія злучэнні мусяць выкарыстоўваць TLS. Рэжымы паскаральніка, перахопу або генерацыі сертыфікатаў не патрэбныя.

Праверце канфігурацыю парсерам перад паўторнай загрузкай патрэбнай службай. Праверка пацвярджае структуру і загрузку сертыфікатаў, а не сеткавую даступнасць. Пасля паспяховай перазагрузкі канфігурацыі зрабіце запыт праз TLS-вузел з дазволенага кліента:

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

Выкарыстоўвайце сапраўднае імя проксі і ўхвалены CA-файл. Публічна даверанаму сертыфікату проксі можа не спатрэбіцца асобны набор. --proxy-cacert наладжвае давер проксі і пакідае праверку мэты асобнай; захоўвайце абедзве праверкі.

Праверце фактычны вузел праслухоўвання і імя сертыфіката, потым выпрабуйце таксама кантраляваную крыніцу, якой трэба адмовіць. Паспяховы разбор сам па сабе не пацвярджае давер кліента або мяжу доступу.