Waarom browsers Squids HTTPS-blokkeringspagina kunnen verbergen
Begrijp waarom een browser zijn eigen tunnel-fout kan tonen in plaats van de aangepaste HTML die wordt teruggegeven voor een geweigerd CONNECT-verzoek.
De aangepaste blokkeringspagina van de proxy verschijnt voor een HTTP-site. Voor een HTTPS-site toont de browser in plaats daarvan een tunnel-fout. De HTML-sjabloon opnieuw vervangen verandert misschien niets.
Met een expliciete HTTP-proxy begint een HTTPS-bezoek meestal met CONNECT. De browser vraagt de proxy een tunnel naar een host en poort te openen. Als Squid dat verzoek weigert, begint de TLS-sessie van de site nooit.
De weigering kan een HTTP-status en antwoordinhoud hebben. U kunt dat mislukte CONNECT-antwoord met curl inspecteren onafhankelijk van de foutpagina van de browser. Dat vereist niet dat de browser de geleverde HTML presenteert als de webpagina van de bestemming. Een browser kan de CONNECT-fouttekst weggooien en zijn eigen proxy-foutinterface gebruiken; de exacte presentatie hangt af van de client.
Als de weigering van Squid al de bedoelde deny_info-inhoud bevat, verandert het bewerken van de tekst, het stylesheet of de bestandsrechten niet welke antwoordfase de browser verwerkt. Houd de weigeringsstatus en het toegangslogboek beschikbaar om vast te stellen of CONNECT is geweigerd en waarom. Een algemene browserpagina kan beleidsdetails verbergen terwijl de proxy de regel correct handhaaft.
Een blokkeringspagina leveren binnen een onderschepte HTTPS-verbinding is een andere architectuur, met TLS-beëindiging, clientvertrouwen en certificaatbeheer. Die wordt niet ingeschakeld door deny_info te bewerken, en een aangepaste sjabloon geeft geen enkele bevoegdheid om de geblokkeerde site na te bootsen. Kies dat ontwerp alleen als het nodig is; gebruik anders de beschikbare foutrapportage van de client en de operationele logboeken van de proxy.