Bakit Maaaring Itago ng mga Browser ang HTTPS Block Page ng Squid

Lumalabas ang custom na block page ng proxy para sa isang HTTP site. Para sa isang HTTPS site, nagpapakita ang browser ng tunnel error sa halip. Maaaring walang mabago sa muling pagpapalit ng HTML template.

Sa isang tahasang HTTP proxy, karaniwang nagsisimula ang pagbisita sa HTTPS sa CONNECT. Hinihiling ng browser sa proxy na magbukas ng tunnel patungo sa isang host at port. Kung tatanggihan ng Squid ang kahilingang iyon, hinding-hindi magsisimula ang TLS session ng site.

Ang pagtanggi ay maaaring may HTTP status at nilalaman ng tugon. Maaari mong suriin ang nabigong CONNECT response na iyon gamit ang curl nang hiwalay sa error page ng browser. Hindi nito kailangang ipakita ng browser ang ibinigay na HTML bilang web page ng destinasyon. Maaaring itapon ng browser ang katawan ng CONNECT error at gamitin ang sarili nitong proxy error interface; ang eksaktong presentasyon ay depende sa client.

Kung ang pagtanggi ng Squid ay mayroon nang inilaan na deny_info body, hindi binabago ng pag-edit sa teksto, stylesheet o mga pahintulot ng file nito kung aling yugto ng tugon ang hinahawakan ng browser. Panatilihing available ang status ng pagtanggi at ang access log upang matukoy kung tinanggihan ang CONNECT at bakit. Maaaring itago ng isang generic na browser page ang mga detalye ng patakaran habang wastong ipinapatupad ng proxy ang panuntunan.

Ang paghahatid ng block page sa loob ng naharang na HTTPS connection ay isa pang arkitektura, na kinabibilangan ng TLS termination, pagtitiwala ng client at paghawak ng sertipiko. Hindi ito pinagana sa pamamagitan ng pag-edit ng deny_info, at ang custom na template ay hindi nagbibigay ng anumang awtoridad na magpanggap bilang na-block na site. Piliin lamang ang disenyong iyon kung kailangan; kung hindi, gamitin ang available na pag-uulat ng error sa client at ang mga operational log ng proxy.