TLS-вузол прямого проксі у Squid 6.13
Додайте TLS-вузол прямого проксі у Squid 6.13 без перехоплення HTTPS-сесії призначення.
Squid 6.13 може приймати запити прямого проксі через TLS, якщо зібраний із GnuTLS або OpenSSL. Це захищає канал клієнт–проксі без перехоплення окремої сесії HTTPS-призначення.
- Отримайте сертифікат для імені хоста, за яким клієнти звертатимуться до Squid. Обмежте приватний ключ службовими ідентичностями, яким він потрібен.
- Додайте 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 налаштовує довіру проксі й лишає перевірку призначення окремою; зберігайте обидві перевірки.
Перевірте фактичний вузол прослуховування та ім’я сертифіката, потім випробуйте також контрольоване джерело, якому слід відмовити. Успішний розбір сам собою не підтверджує довіру клієнта чи межу доступу.