Waarom blaaiers Squid se HTTPS-blokblad kan versteek
Verstaan waarom 'n blaaier sy eie tonnelfout kan wys in plaas van die pasgemaakte HTML wat vir 'n geweierde CONNECT-versoek teruggegee word.
Die pasgemaakte blokblad van die proxy verskyn vir 'n HTTP-werf. Vir 'n HTTPS-werf wys die blaaier eerder 'n tonnelfout. Om die HTML-sjabloon weer te vervang, verander moontlik niks.
Met 'n eksplisiete HTTP-proxy begin 'n HTTPS-besoek gewoonlik met CONNECT. Die blaaier vra die proxy om 'n tonnel na 'n gasheer en poort oop te maak. As Squid daardie versoek verwerp, begin die webwerf se TLS-sessie nooit nie.
Die verwerping kan 'n HTTP-status en responsinhoud hê. Jy kan daardie mislukte CONNECT-respons met curl ondersoek onafhanklik van die blaaier se foutblad. Dit vereis nie dat die blaaier die verskafde HTML as die bestemming se webblad aanbied nie. 'n Blaaier kan die CONNECT-foutliggaam weggooi en sy eie proxyfoutkoppelvlak gebruik; die presiese voorstelling hang van die kliënt af.
As Squid se verwerping reeds die bedoelde deny_info-liggaam bevat, verander die wysiging van die teks, stylesheet of lêertoestemmings nie watter responsstadium die blaaier hanteer nie. Hou die verwerpingsstatus en toegangslog beskikbaar om vas te stel of CONNECT geweier is en waarom. 'n Algemene blaaierblad kan beleidsbesonderhede verberg terwyl die proxy die reël korrek afdwing.
Om 'n blokblad binne 'n onderskepte HTTPS-verbinding te bedien, is 'n ander argitektuur wat TLS-beëindiging, kliëntvertroue en sertifikaathantering behels. Dit word nie deur die wysiging van deny_info geaktiveer nie, en 'n pasgemaakte sjabloon gee geen gesag om die geblokkeerde werf na te boots nie. Kies daardie ontwerp net indien nodig; gebruik andersins die kliënt se beskikbare foutrapportering en die proxy se bedryfslogboeke.