Služba HTTPS na portu 8443 může přes správně nastavenou proxy Squid selhávat, i když běžné HTTPS na 443 funguje. Než změníte protokol proxy v klientovi, prověřte odmítnutí CONNECT a zásady pro cílové porty.

V typických pravidlech přístupu Squidu 6.13 záleží na dvou kontrolách: cíl musí projít Safe_ports a CONNECT musí projít SSL_ports. Přidání portu jen do jedné ACL může ponechat druhé odmítnutí v platnosti.

Stávající definice rozšiřujte uváženě

Pro pravidla povolující běžné webové porty a jeden další port HTTPS:

acl Safe_ports port 80 443 8443
acl SSL_ports port 443 8443

Příslušné definice nahraďte nebo upravte, aby nezůstala platná neočekávaná starší sada hodnot. Zachovejte běžná pravidla odmítání nebezpečných portů a CONNECT i zamýšlená omezení klientů.

Výjimku omezte úzce

Je-li další port potřeba jen pro jeden kontrolovaný cíl, přidejte před pravidlo povolující klienta cílené odmítnutí:

acl extra_tls_port port 8443
acl approved_tls_target dst 203.0.113.20/32
http_access deny CONNECT extra_tls_port !approved_tls_target

Adresa je zástupný údaj pro dokumentaci. Použijte cíl, který spravujete nebo ke kterému máte oprávněný přístup, a zohledněte skutečné změny jeho adresy. Tím omezíte výjimku pro další port, místo abyste na 8443 povolili všechny cíle.

Nechte zpracovat celou aktivní konfiguraci a zkontrolujte pořadí pravidel. Správně napsané odmítnutí umístěné za odpovídajícím pravidlem povolujícím klienta zamýšlené omezení nezajistí.

Otestujte schválený název hostitele se skutečným certifikátem a portem a potom kontrolovaný cíl, který má zůstat zakázaný. Zapnuté ověřování TLS umožňuje odlišit chyby identity cíle od chyb zásad proxy. Neodstraňujte celou ochranu CONNECT, jen aby fungoval jeden požadavek na vlastní port.

Související články