Usługa HTTPS na porcie 8443 może nie działać przez poprawnie skonfigurowany serwer proxy Squid, nawet gdy zwykły HTTPS na 443 działa. Zanim zmienisz protokół proxy klienta, sprawdź odmowę CONNECT i reguły dotyczące portów docelowych.

W typowej polityce dostępu Squid 6.13 istotne są dwa sprawdzenia: cel musi przejść Safe_ports, a CONNECT musi przejść SSL_ports. Dodanie portu tylko do jednej listy ACL może pozostawić drugą odmowę w mocy.

Rozszerz istniejące definicje w przemyślany sposób

Dla polityki zezwalającej na zwykłe porty WWW i jeden dodatkowy port HTTPS:

acl Safe_ports port 80 443 8443
acl SSL_ports port 443 8443

Zastąp lub edytuj odpowiednie definicje, aby nie pozostawić nieoczekiwanego starego zestawu wartości. Zachowaj zwykłe reguły odmowy dla niebezpiecznych portów i CONNECT oraz zamierzone ograniczenia klientów.

Ogranicz zakres wyjątku

Jeśli dodatkowy port jest potrzebny tylko dla jednego kontrolowanego celu, dodaj ukierunkowaną odmowę przed regułą zezwalającą klientowi:

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

Adres jest przykładową wartością do dokumentacji. Użyj celu, którym administrujesz lub do którego masz uprawniony dostęp, i uwzględnij rzeczywiste zmiany jego adresu. Ogranicza to wyjątek dla dodatkowego portu zamiast zezwalać na wszystkie cele na 8443.

Przeprowadź analizę całej aktywnej konfiguracji i sprawdź kolejność reguł. Poprawnie zapisana odmowa umieszczona po pasującej regule zezwalającej klientowi nie zapewni zamierzonego ograniczenia.

Przetestuj zatwierdzoną nazwę hosta z jej rzeczywistym certyfikatem i portem, a następnie kontrolowany cel, który nadal powinien być blokowany. Pozostaw włączoną weryfikację TLS, aby odróżnić błędy tożsamości celu od błędów polityki proxy. Nie usuwaj całej ochrony CONNECT, by uruchomić jedno żądanie na niestandardowym porcie.

Powiązane artykuły