Kvifor nettlesarar kan skjule HTTPS-blokkeringssida til Squid

Den tilpassa blokkeringssida til proxyen vert vist for eit HTTP-nettstad. For eit HTTPS-nettstad viser nettlesaren i staden ein tunnefeil. Å bytte ut HTML-malen på nytt endrar kanskje ingenting.

Med ein eksplisitt HTTP-proxy byrjar eit HTTPS-besøk vanlegvis med CONNECT. Nettlesaren ber proxyen opne ein tunnel til ein vert og port. Viss Squid avviser den førespurnaden, startar aldri TLS-økta til nettstaden.

Avvisinga kan ha ein HTTP-status og eit svarinnhald. Du kan granske det mislukka CONNECT-svaret med curl uavhengig av feilsida til nettlesaren. Det krev ikkje at nettlesaren presenterer den leverte HTML-en som nettsida til destinasjonen. Ein nettlesar kan kaste CONNECT-feilinnhaldet og bruke sitt eige proxy-feilgrensesnitt; den nøyaktige presentasjonen er avhengig av klienten.

Viss avvisinga frå Squid alt inneheld det tiltenkte deny_info-innhaldet, endrar ikkje redigering av teksten, stilarket eller filrettane kva svarsteg nettlesaren handsamar. Hald avvisingsstatusen og tilgangsloggen tilgjengelege for å fastslå om CONNECT vart avvist og kvifor. Ei generell nettlesarside kan skjule retningslinjedetaljar medan proxyen handhevar regelen rett.

Å levere ei blokkeringsside inne i ei avlytta HTTPS-tilkopling er ein annan arkitektur, som involverer TLS-avslutning, klienttillit og handtering av sertifikat. Han vert ikkje slått på ved å redigere deny_info, og ein tilpassa mal gir inga mynde til å etterlikne den blokkerte nettstaden. Vel den utforminga berre viss det er naudsynt; elles bruk den tilgjengelege feilrapporteringa til klienten og driftsloggane til proxyen.