Intercettazione Squid contro autenticazione proxy esplicita
Spiegare perché la normale autenticazione proxy esplicita non può essere semplicemente aggiunta a un listener di intercettazione Squid.
Un client proxy esplicito sa di parlare con un proxy. Un browser intercettato crede di essersi connesso al sito web. Questa differenza è centrale per l'autenticazione.
La normale autenticazione proxy usa una sfida proxy e una risposta di autorizzazione proxy. Un client che non ha scelto un proxy non dovrebbe inviare con leggerezza credenziali proxy a un intermediario inatteso.
Per questo la guida all'intercettazione di Squid non supporta la semplice combinazione di proxy_auth con la modalità di intercettazione. Un helper di autenticazione Basic funzionante non cambia ciò che il browser ritiene sia l'endpoint remoto.
Se utenti identificati necessitano di un normale proxy forward autenticato, configurare i client in modo esplicito, direttamente o tramite una configurazione proxy gestita appropriata. Tenere quel listener e la sua politica di autenticazione distinti da un listener di intercettazione.
Un portale di autenticazione, un sistema di identità a livello di rete o una disposizione di intercettazione TLS sono un altro progetto con requisiti di fiducia e distribuzione diversi. Non sono una correzione di una riga per lo scambio proxy esplicito mancante.
Non risolvere l'assenza di una richiesta rendendo pubblico il servizio intercettato o consentendo ogni client. Decidere prima se il requisito è l'autenticazione esplicita dell'utente o l'intercettazione di traffico mai configurato per un proxy. Richiedono presupposti diversi.