Hvorfor nettlesere kan skjule Squids HTTPS-blokkeringsside
Forstå hvorfor en nettleser kan vise sin egen tunneleil i stedet for den tilpassede HTML-en som returneres for en avvist CONNECT-forespørsel.
Proxyens tilpassede blokkeringsside vises for et HTTP-nettsted. For et HTTPS-nettsted viser nettleseren i stedet en tunneleil. Å bytte ut HTML-malen igjen endrer kanskje ingenting.
Med en eksplisitt HTTP-proxy begynner et HTTPS-besøk vanligvis med CONNECT. Nettleseren ber proxyen åpne en tunnel til en vert og port. Hvis Squid avviser den forespørselen, starter nettstedets TLS-økt aldri.
Avvisningen kan ha en HTTP-status og et svarinnhold. Du kan undersøke det mislykkede CONNECT-svaret med curl uavhengig av nettleserens feilside. Det krever ikke at nettleseren presenterer den leverte HTML-en som nettstedets nettside. En nettleser kan forkaste CONNECT-feilens innhold og bruke sitt eget proxy-feilgrensesnitt; den nøyaktige presentasjonen avhenger av klienten.
Hvis Squids avvisning allerede inneholder det tiltenkte deny_info-innholdet, endrer ikke redigering av teksten, stilarket eller filrettighetene hvilket svarsteg nettleseren behandler. Hold avvisningsstatusen og tilgangsloggen tilgjengelige for å fastslå om CONNECT ble avvist og hvorfor. En generisk nettleserside kan skjule policy-detaljer mens proxyen håndhever regelen riktig.
Å levere en blokkeringsside inne i en avlyttet HTTPS-tilkobling er en annen arkitektur, som involverer TLS-avslutning, klienttillit og håndtering av sertifikater. Den aktiveres ikke ved å redigere deny_info, og en tilpasset mal gir ingen myndighet til å etterligne det blokkerte nettstedet. Velg den utformingen bare hvis det er nødvendig; ellers bruk klientens tilgjengelige feilrapportering og proxyens driftslogger.