Perché i browser possono nascondere la pagina di blocco HTTPS di Squid
Capite perché un browser può mostrare il proprio errore di tunnel invece dell'HTML personalizzato restituito per una richiesta CONNECT negata.
La pagina di blocco personalizzata del proxy appare per un sito HTTP. Per un sito HTTPS, il browser mostra invece un errore di tunnel. Sostituire di nuovo il modello HTML potrebbe non cambiare nulla.
Con un proxy HTTP esplicito, una visita HTTPS inizia di solito con CONNECT. Il browser chiede al proxy di aprire un tunnel verso un host e una porta. Se Squid rifiuta quella richiesta, la sessione TLS del sito non inizia mai.
Il rifiuto può avere uno stato HTTP e un contenuto di risposta. Potete ispezionare quella risposta CONNECT fallita con curl indipendentemente dalla pagina di errore del browser. Ciò non richiede che il browser presenti l'HTML fornito come pagina web della destinazione. Un browser può scartare il corpo dell'errore CONNECT e usare la propria interfaccia di errore del proxy; la presentazione esatta dipende dal client.
Se il rifiuto di Squid contiene già il corpo deny_info previsto, modificare il testo, il foglio di stile o i permessi del file non cambia quale fase della risposta gestisce il browser. Tenete disponibili lo stato del rifiuto e il registro di accesso per stabilire se CONNECT è stato negato e perché. Una pagina generica del browser può nascondere i dettagli della politica mentre il proxy applica correttamente la regola.
Servire una pagina di blocco all'interno di una connessione HTTPS intercettata è un'altra architettura, che implica terminazione TLS, fiducia del client e gestione dei certificati. Non viene abilitata modificando deny_info, e un modello personalizzato non conferisce alcuna autorità per impersonare il sito bloccato. Scegliete quel progetto solo se necessario; altrimenti usate la segnalazione degli errori disponibile nel client e i registri operativi del proxy.