Interception de Squid face à l'authentification proxy explicite

Un client proxy explicite sait qu'il parle à un proxy. Un navigateur intercepté croit s'être connecté au site web. Cette différence est centrale pour l'authentification.

L'authentification proxy ordinaire utilise un défi proxy et une réponse d'autorisation proxy. Un client qui n'a pas choisi de proxy ne devrait pas envoyer négligemment des identifiants proxy à un intermédiaire inattendu.

Les recommandations d'interception de Squid ne prennent donc pas en charge la simple combinaison de proxy_auth avec le mode interception. Un assistant d'authentification Basic qui fonctionne ne change pas ce que le navigateur croit être le point de terminaison distant.

Si des utilisateurs identifiés ont besoin d'un proxy mandataire authentifié ordinaire, configurez les clients explicitement, directement ou via une configuration de proxy gérée appropriée. Gardez cet écouteur et sa politique d'authentification distincts d'un écouteur d'interception.

Un portail d'authentification, un système d'identité au niveau du réseau ou un dispositif d'interception TLS relèvent d'une autre conception, avec des exigences de confiance et de déploiement différentes. Ce n'est pas une réparation d'une ligne pour l'échange proxy explicite manquant.

Ne résolvez pas l'absence d'invite en rendant public le service intercepté ou en autorisant tous les clients. Décidez d'abord si l'exigence est une authentification explicite de l'utilisateur ou une interception de trafic qui n'a jamais été configuré pour un proxy. Ces deux cas supposent des choses différentes.