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 настройва доверието към проксито и оставя проверката на целта отделна; запазете двете проверки.

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

Подобни статии