Pourquoi les navigateurs peuvent masquer la page de blocage HTTPS de Squid
Comprenez pourquoi un navigateur peut afficher sa propre erreur de tunnel au lieu du HTML personnalisé renvoyé pour une requête CONNECT refusée.
La page de blocage personnalisée du proxy apparaît pour un site HTTP. Pour un site HTTPS, le navigateur affiche à la place une erreur de tunnel. Remplacer à nouveau le modèle HTML peut ne rien changer.
Avec un proxy HTTP explicite, une visite HTTPS commence généralement par CONNECT. Le navigateur demande au proxy d'ouvrir un tunnel vers un hôte et un port. Si Squid rejette cette requête, la session TLS du site ne démarre jamais.
Le rejet peut avoir un statut HTTP et un contenu de réponse. Vous pouvez inspecter cette réponse CONNECT échouée avec curl indépendamment de la page d'erreur du navigateur. Cela n'exige pas que le navigateur présente le HTML fourni comme la page web de la destination. Un navigateur peut ignorer le corps de l'erreur CONNECT et utiliser sa propre interface d'erreur de proxy ; la présentation exacte dépend du client.
Si le rejet de Squid contient déjà le corps deny_info prévu, modifier son texte, sa feuille de style ou les permissions du fichier ne change pas l'étape de réponse que le navigateur traite. Gardez le statut de rejet et le journal d'accès disponibles pour établir si CONNECT a été refusé et pourquoi. Une page de navigateur générique peut masquer les détails de la politique alors que le proxy applique correctement la règle.
Servir une page de blocage dans une connexion HTTPS interceptée est une autre architecture, impliquant la terminaison TLS, la confiance du client et la gestion des certificats. Elle n'est pas activée en modifiant deny_info, et un modèle personnalisé ne confère aucune autorité pour usurper le site bloqué. Choisissez cette conception uniquement si nécessaire ; sinon, utilisez les rapports d'erreur disponibles du client et les journaux d'exploitation du proxy.