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 ја поставува довербата во проксито и ја остава проверката на целта одделна; задржете ги двете проверки.

Проверете ги вистинскиот слушател и името на сертификатот, потоа тестирајте и контролиран извор што треба да биде одбиен. Само успешно парсирање не ја утврдува довербата на клиентот или границата на пристап.

Поврзани статии