Wêrom browsers de HTTPS-blokside fan Squid ferbergje kinne
Begryp wêrom't in browser syn eigen tunnelflater toane kin ynstee fan 'e oanpaste HTML dy't weromjûn wurdt foar in wegere CONNECT-oanfraach.
De oanpaste blokside fan 'e proxy ferskynt foar in HTTP-side. Foar in HTTPS-side toant de browser ynstee in tunnelflater. It HTML-sjabloan nochris ferfange kin neat feroarje.
Mei in eksplisite HTTP-proxy begjint in HTTPS-besite meastentiids mei CONNECT. De browser freget de proxy om in tunnel nei in host en poarte te iepenjen. As Squid dy oanfraach wegere, begjint de TLS-sesje fan 'e side nea.
De wegering kin in HTTP-status en antwurdynhâld hawwe. Jo kinne dat mislearre CONNECT-antwurd mei curl besjen los fan 'e flaterpagina fan 'e browser. Dat freget net dat de browser de oanlevere HTML as de webpagina fan 'e bestemming presintearret. In browser kin it flaterlichem fan CONNECT fuortsmite en syn eigen proxy-flaterynterface brûke; de krekte presintaasje hinget fan 'e klant ôf.
As de wegering fan Squid al it bedoelde deny_info-lichem befettet, feroaret it bewurkjen fan 'e tekst, it stylblêd of de bestânsrjochten net hokker antwurdstap de browser behannelet. Hâld de wegeringsstatus en it tagongslogboek beskikber om fêst te stellen oft CONNECT wegere is en wêrom. In algemiene browserpagina kin beliedsdetails ferbergje wylst de proxy de regel goed hanthavent.
In blokside jaan binnen in ûnderskepte HTTPS-ferbining is in oare arsjitektuer, mei TLS-beëiniging, klantbetrouwen en sertifikaatbehear. It wurdt net ynskeakele troch deny_info te bewurkjen, en in oanpast sjabloan jout gjin foech om de blokkearre side nei te bearen. Kies dat ûntwerp allinnich as it nedich is; brûk oars de beskikbere flaterrapportaazje fan 'e klant en de operasjonele logboeken fan 'e proxy.