De ce browserele pot ascunde pagina de blocare HTTPS a Squid
Înțelegeți de ce un browser poate afișa propria eroare de tunel în locul HTML-ului personalizat returnat pentru o cerere CONNECT refuzată.
Pagina de blocare personalizată a proxy-ului apare pentru un site HTTP. Pentru un site HTTPS, browserul afișează în schimb o eroare de tunel. Înlocuirea din nou a șablonului HTML poate să nu schimbe nimic.
Cu un proxy HTTP explicit, o vizită HTTPS începe de obicei cu CONNECT. Browserul cere proxy-ului să deschidă un tunel către un host și un port. Dacă Squid respinge acea cerere, sesiunea TLS a site-ului nu începe niciodată.
Respingerea poate avea un status HTTP și conținut de răspuns. Puteți inspecta acel răspuns CONNECT eșuat cu curl independent de pagina de eroare a browserului. Aceasta nu cere browserului să prezinte HTML-ul furnizat ca pagina web a destinației. Un browser poate arunca corpul erorii CONNECT și poate folosi propria interfață de eroare a proxy-ului; prezentarea exactă depinde de client.
Dacă respingerea Squid conține deja corpul deny_info dorit, editarea textului, a foii de stil sau a permisiunilor fișierului nu schimbă etapa de răspuns pe care o gestionează browserul. Păstrați disponibile statusul respingerii și jurnalul de acces pentru a stabili dacă CONNECT a fost refuzat și de ce. O pagină generică a browserului poate ascunde detalii ale politicii în timp ce proxy-ul aplică corect regula.
Servirea unei pagini de blocare într-o conexiune HTTPS interceptată este o altă arhitectură, care implică terminarea TLS, încrederea clientului și gestionarea certificatelor. Nu este activată prin editarea deny_info, iar un șablon personalizat nu oferă nicio autoritate de a imita site-ul blocat. Alegeți acest design doar dacă este necesar; altfel, folosiți raportarea erorilor disponibilă în client și jurnalele operaționale ale proxy-ului.