Kial retumiloj povas kaŝi la HTTPS-blokpaĝon de Squid
Komprenu, kial retumilo povas montri sian propran tunelan eraron anstataŭ la propran HTML-on redonitan por rifuzita CONNECT-peto.
La propra blokpaĝo de la prokurilo aperas por HTTP-ejo. Por HTTPS-ejo, la retumilo anstataŭe montras tunelan eraron. Anstataŭigi la HTML-ŝablonon denove eble tute ne ŝanĝos ion.
Kun eksplicita HTTP-prokurilo, HTTPS-vizito kutime komenciĝas per CONNECT. La retumilo petas al la prokurilo malfermi tunelon al gastiganto kaj pordo. Se Squid rifuzas tiun peton, la TLS-sesio de la retejo neniam komenciĝas.
La rifuzo povas havi HTTP-statuson kaj respondan enhavon. Vi povas esplori tiun malsukcesan CONNECT-respondon per curl sendepende de la erarpaĝo de la retumilo. Tio ne postulas, ke la retumilo prezentu la provizitan HTML-on kiel la retpaĝon de la celo. Retumilo povas forĵeti la eraran korpon de CONNECT kaj uzi sian propran prokuran erarinterfacon; la preciza prezento dependas de la kliento.
Se la rifuzo de Squid jam enhavas la celatan korpon deny_info, redakti ĝian tekston, stilfolion aŭ dosierpermesojn ne ŝanĝas, kiun respondan stadion la retumilo pritraktas. Tenu la rifuzan statuson kaj alirprotokolon disponeblaj por konstati, ĉu CONNECT estis rifuzita kaj kial. Ĝenerala retumila paĝo povas kaŝi politikajn detalojn dum la prokurilo ĝuste plenumas la regulon.
Servi blokpaĝon ene de interceptita HTTPS-konekto estas alia arkitekturo, kun TLS-finigo, klienta fido kaj atestila administrado. Ĝi ne aktiviĝas per redaktado de deny_info, kaj propra ŝablono donas neniun rajtigon al personigi la blokitan retejon. Elektu tiun dezajnon nur se necese; alie uzu la disponeblan erar-raportadon de la kliento kaj la funkciajn protokolojn de la prokurilo.