Hvorfor browsere kan skjule Squids HTTPS-blokeringsside
Forstå, hvorfor en browser kan vise sin egen tunnelejl i stedet for den tilpassede HTML, der returneres for en afvist CONNECT-anmodning.
Proxys tilpassede blokeringsside vises for et HTTP-websted. For et HTTPS-websted viser browseren i stedet en tunnelejl. Udskiftning af HTML-skabelonen igen ændrer måske intet.
Med en eksplicit HTTP-proxy begynder et HTTPS-besøg normalt med CONNECT. Browseren beder proxyen om at åbne en tunnel til en vært og port. Hvis Squid afviser den anmodning, starter webstedets TLS-session aldrig.
Afvisningen kan have en HTTP-status og et svarbody. Du kan undersøge det mislykkede CONNECT-svar med curl uafhængigt af browserens fejlside. Det kræver ikke, at browseren præsenterer den leverede HTML som destinationens webside. En browser kan kassere CONNECT-fejlens body og bruge sin egen proxy-fejlgrænseflade; den præcise præsentation afhænger af klienten.
Hvis Squids afvisning allerede indeholder det tilsigtede deny_info-body, ændrer redigering af tekst, typografiark eller filrettigheder ikke, hvilken svardel browseren behandler. Hold afvisningsstatussen og adgangsloggen tilgængelige for at fastslå, om CONNECT blev afvist og hvorfor. En generisk browserside kan skjule politikdetaljer, mens proxyen håndhæver reglen korrekt.
At levere en blokeringsside inde i en aflyttet HTTPS-forbindelse er en anden arkitektur, der involverer TLS-afslutning, klienttillid og certifikathåndtering. Den aktiveres ikke ved at redigere deny_info, og en tilpasset skabelon giver ingen ret til at efterligne det blokerede websted. Vælg kun det design, hvis det er nødvendigt; brug ellers klientens tilgængelige fejlrapportering og proxyens driftslogfiler.