Varför webbläsare kan dölja Squids HTTPS-blockeringssida
Förstå varför en webbläsare kan visa sitt eget tunnelfel i stället för den anpassade HTML som returneras för en avvisad CONNECT-begäran.
Proxyns anpassade blockeringssida visas för en HTTP-webbplats. För en HTTPS-webbplats visar webbläsaren i stället ett tunnelfel. Att byta ut HTML-mallen igen ändrar kanske ingenting.
Med en explicit HTTP-proxy börjar ett HTTPS-besök vanligtvis med CONNECT. Webbläsaren ber proxyn öppna en tunnel till en värd och port. Om Squid avvisar den begäran startar webbplatsens TLS-session aldrig.
Avvisningen kan ha en HTTP-status och ett svarsinnehåll. Du kan undersöka det misslyckade CONNECT-svaret med curl oberoende av webbläsarens felsida. Det kräver inte att webbläsaren presenterar den levererade HTML:en som destinationens webbsida. En webbläsare kan kasta bort CONNECT-felets brödtext och använda sitt eget proxy-felgränssnitt; den exakta presentationen beror på klienten.
Om Squids avvisning redan innehåller det avsedda deny_info-innehållet ändrar inte redigering av texten, stilmallen eller filbehörigheterna vilket svarsteg webbläsaren hanterar. Håll avvisningsstatusen och åtkomstloggen tillgängliga för att fastställa om CONNECT avvisades och varför. En allmän webbläsarsida kan dölja policydetaljer medan proxyn tillämpar regeln korrekt.
Att servera en blockeringssida i en avlyssnad HTTPS-anslutning är en annan arkitektur, som involverar TLS-avslutning, klientförtroende och hantering av certifikat. Den aktiveras inte genom att redigera deny_info, och en anpassad mall ger ingen befogenhet att utge sig för den blockerade webbplatsen. Välj den designen bara om det behövs; annars använd klientens tillgängliga felrapportering och proxyns driftloggar.