Služba HTTPS na porte 8443 môže cez správne nastavený proxy server Squid zlyhávať, aj keď bežné HTTPS na 443 funguje. Pred zmenou proxy protokolu klienta preskúmajte odmietnutie CONNECT a pravidlá cieľových portov.

V typickej politike prístupu Squidu 6.13 sú dôležité dve kontroly: cieľ musí prejsť Safe_ports a CONNECT musí prejsť SSL_ports. Pridanie portu len do jednej ACL môže ponechať druhé odmietnutie v platnosti.

Existujúce definície rozširujte uvážene

Pre politiku povoľujúcu bežné webové porty a jeden ďalší port HTTPS:

acl Safe_ports port 80 443 8443
acl SSL_ports port 443 8443

Príslušné definície nahraďte alebo upravte, aby nezostala platná nečakaná staršia množina hodnôt. Zachovajte bežné pravidlá odmietania nebezpečných portov a CONNECT aj zamýšľané obmedzenia klientov.

Výnimku úzko obmedzte

Ak je ďalší port potrebný len pre jeden kontrolovaný cieľ, pridajte cielené odmietnutie pred pravidlo povoľujúce klienta:

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 pre dokumentáciu. Použite cieľ, ktorý spravujete alebo ku ktorému máte oprávnený prístup, a zohľadnite skutočné zmeny jeho adresy. Tým obmedzíte výnimku pre ďalší port namiesto povolenia všetkých cieľov na 8443.

Nechajte spracovať celú aktívnu konfiguráciu a skontrolujte poradie pravidiel. Správne napísané odmietnutie za zodpovedajúcim pravidlom povoľujúcim klienta nezabezpečí zamýšľané obmedzenie.

Otestujte schválený názov hostiteľa so skutočným certifikátom a portom a potom kontrolovaný cieľ, ktorý má zostať zakázaný. Ponechajte zapnuté overovanie TLS, aby ste odlíšili chyby identity cieľa od chýb pravidiel proxy. Neodstraňujte celú ochranu CONNECT, len aby fungovala jedna požiadavka na vlastný port.

Súvisiace články