Proxy par profil : DNS, authentification et modes de défaillance

Ce guide prend le comportement réseau documenté de Chromium comme référence. D’autres navigateurs et produits peuvent faire des choix différents, et un gestionnaire peut ajouter un courtier réseau local autour de Chromium. Vérifiez le comportement de la version exacte que vous exploitez.

Commencer par quatre questions indépendantes

Un enregistrement de proxy contient généralement un schéma, une extrémité, un port et parfois une référence d’authentification. Il laisse quatre questions de politique distinctes :

1. Couverture : quelles requêtes et quels protocoles du navigateur sont attribués à ce proxy ?
2. Résolution de noms : l’appareil ou le proxy résout-il le nom d’hôte de destination ?
3. Authentification : quelles associations de client et de schéma de proxy fonctionnent, et où les identifiants sont-ils stockés ?
4. Défaillance : une erreur de connexion arrête-t-elle la requête, essaie-t-elle un autre proxy ou revient-elle à une route directe ?

Traiter ces questions comme un seul interrupteur « proxy activé » provoque la plupart des surprises. Chromium documente la sélection du proxy comme une résolution au niveau de l’URL : une URL produit une liste ordonnée de choix de proxys avant même la résolution éventuelle de la destination. Les règles de contournement et de repli font partie de cette décision.

Ce que couvre un proxy par profil

La politique ProxySettings de Google s’applique au niveau du profil Chrome. Elle permet de choisir un mode direct, système, autodétecté, à serveur fixe ou à script PAC, avec des champs explicites de contournement et d’obligation du PAC.

Cette limite est plus étroite que celle d’un VPN ou d’un espace de noms réseau du système d’exploitation. Elle gouverne les requêtes traitées par le contexte réseau du navigateur. Elle ne gouverne pas automatiquement :

• les propres appels d’API du gestionnaire de bureau ;
• une application hors processus ou l’outil de mise à jour du navigateur ;
• les contrôles de DNS et de connectivité du système d’exploitation ;
• une autre application lancée depuis un fichier téléchargé ;
• l’utilitaire natif distinct d’une extension ;
• les services locaux atteints par des contournements implicites de l’interface de bouclage ; ou
• le trafic utilisant un protocole que le chemin de proxy sélectionné ne peut pas transporter.

Certains de ces composants peuvent disposer de leur propre prise en charge des proxys. Elle doit être spécifiée et testée séparément. Une déclaration de produit telle que « le trafic du profil utilise ce proxy » doit indiquer les processus et protocoles inclus au lieu de laisser entendre un routage de tout l’appareil.

Suivre une requête HTTPS

Le chemin d’une navigation HTTPS normale comporte plusieurs étapes.

1. Choisir la route

Le navigateur évalue des règles fixes, un script de configuration automatique du proxy ou les paramètres du système. Une correspondance de contournement peut sélectionner une connexion directe. Une liste de proxys peut définir un proxy principal suivi d’alternatives, notamment DIRECT si le repli direct est autorisé.

Chromium applique aussi des contournements implicites aux destinations localhost et link-local. Cela protège les origines locales contre des paramètres de proxy contrôlés de l’extérieur, mais exige de nuancer toute description couvrant « tout le trafic ».

2. Résoudre et joindre le proxy

Si l’extrémité du proxy est un nom d’hôte, l’appareil doit toujours pouvoir le résoudre et s’y connecter. Une résolution distante de la destination ne supprime pas cette recherche initiale. Son échec diffère du cas où le proxy est accessible, mais ne peut pas résoudre la destination.

3. S’authentifier auprès du proxy

Un proxy HTTP qui exige des identifiants renvoie normalement 407 Proxy Authentication Required avec une demande d’authentification. La RFC 9110 définit cet échange et les champs Proxy-Authenticate et Proxy-Authorization.

Chromium n’utilise pas le nom d’utilisateur et le mot de passe intégrés aux paramètres manuels du proxy. Sa documentation sur les proxys précise que l’authentification suit plutôt le flux ordinaire des identifiants du navigateur. Un gestionnaire de profils doit donc fournir une intégration explicite pour la demande prise en charge, et non promettre que toute chaîne utilisateur:motdepasse@hote fonctionnera.

4. Établir la connexion à la destination

Avec un proxy HTTP, Chromium délègue au proxy la résolution du nom de destination. Pour une destination HTTPS, le navigateur demande au proxy de créer un tunnel CONNECT, puis effectue un TLS de bout en bout avec la destination à travers ce tunnel.

Le proxy apprend toujours le nom d’hôte de destination et les métadonnées de connexion. Lorsque le lien entre le client et le proxy utilise HTTP en clair, la requête CONNECT et son nom d’hôte ne sont pas protégés sur ce lien. Un proxy HTTPS ajoute TLS entre le navigateur et le proxy, protégeant ces métadonnées des observateurs intermédiaires. Il n’empêche pas le proxy lui-même de voir la destination demandée.

Le proxy ne peut normalement pas lire le contenu de la page HTTPS transportée dans le tunnel. L’interception TLS relève d’un autre modèle de confiance : le client accorde sa confiance à une autorité de certification qui permet à l’intermédiaire de terminer et de recréer TLS. Elle ne doit jamais être silencieusement confondue avec un simple acheminement.

Le traitement DNS change selon le schéma du proxy

Le comportement documenté de Chromium diffère selon le type de proxy :

Route sélectionnée	Résolution du nom de destination dans Chromium	Limite importante
Directe ou contournée	Résolveur de l’appareil ou du navigateur	Le trafic de destination sort sans le proxy du profil
Proxy HTTP	Côté proxy	Le transport HTTP en clair entre client et proxy expose les requêtes HTTP ; HTTPS utilise CONNECT
Proxy HTTPS	Côté proxy	Le client doit valider le certificat TLS du proxy
Proxy SOCKS4	Côté client	Destination IPv4 uniquement ; Chromium n’implémente pas le repli SOCKS4a
Proxy SOCKS5	Côté proxy	Chromium l’utilise pour les requêtes URL TCP et ne documente aucune prise en charge de l’authentification SOCKS5

La RFC 1928 autorise une requête SOCKS5 à transporter un nom de domaine et définit plusieurs identifiants de méthodes d’authentification. Une capacité du protocole ne garantit pas son implémentation dans le client. Chromium envoie actuellement les noms de destination à un proxy SOCKS5, mais indique que son client intégré ne prend en charge aucune méthode d’authentification SOCKS5. Un fournisseur proposant SOCKS5 avec nom d’utilisateur et mot de passe peut donc exiger un intermédiaire pris en charge ou un autre schéma. Confirmez l’implémentation du navigateur avant d’accepter l’enregistrement.

DNS-over-HTTPS ajoute une couche. La politique DnsOverHttpsMode de Chrome distingue automatic, qui peut revenir à un DNS non sécurisé, de secure, qui fait échouer la résolution lorsque le DNS sécurisé échoue. Cette politique est documentée au niveau du navigateur, tandis que ProxySettings l’est au niveau du profil. Ce décalage est un avertissement utile : le mot « profil » sur un réglage ne signifie pas que tous les contrôles DNS ont le même périmètre.

Un produit qui exécute chaque profil dans un processus de navigateur distinct peut créer une limite effective plus étroite, mais il s’agit d’un choix d’implémentation. Testez-le. Les preuves doivent distinguer :

• la résolution de l’extrémité du proxy ;
• la résolution de la destination demandée ;
• le DNS utilisé par les requêtes directes ou contournées ;
• l’amorçage et le repli du DNS sécurisé ; et
• le DNS effectué par les composants hors du contexte réseau du profil.

L’authentification pose un problème de compatibilité et de gestion des secrets

Chromium documente Basic, Digest, Negotiate et NTLM pour les proxys HTTP. Les proxys HTTPS ajoutent un canal protégé entre le client et le proxy et peuvent aussi prendre en charge des certificats clients. Le client de proxy intégré de Chromium n’implémente pas l’authentification SOCKS4 ou SOCKS5, même si la spécification SOCKS5 prévoit des méthodes d’authentification.

Même un schéma compatible peut être dangereux sur un transport inadapté. La RFC 7617 explique que les identifiants Basic sont seulement encodés en Base64 et exigent un canal protégé tel que TLS. L’authentification Basic auprès d’un proxy HTTP en clair expose le mot de passe à toute personne capable d’observer ce lien.

Un gestionnaire de profils doit séparer les données suivantes :

• les métadonnées non secrètes de l’extrémité, comme le schéma, l’hôte, le port et le libellé du fournisseur ;
• une référence de secret utilisée par le service de cycle de vie ou de réseau ;
• la valeur de l’identifiant dans un stockage protégé ;
• l’état de connexion expurgé pour l’interface et la piste d’audit ; et
• le détail de diagnostic disponible uniquement dans un flux d’assistance contrôlé.

Les écrans, journaux, API, exports et sorties d’automatisation ordinaires n’ont pas besoin du mot de passe du proxy. Un opérateur doit généralement savoir que l’authentification a échoué, quel schéma a été demandé, quelle extrémité était concernée et si un repli s’est produit.

Modes de défaillance et symptômes

Défaillance	Symptôme probable	Limite à vérifier
Mauvais schéma de proxy	Échec de la négociation TLS ou du protocole	Une extrémité HTTPS a-t-elle été déclarée comme HTTP, ou l’inverse ?
Nom d’hôte du proxy impossible à résoudre	La connexion échoue avant d’atteindre le proxy	Quel résolveur a effectué la recherche initiale ?
Port du proxy inaccessible	Délai dépassé ou connexion refusée	Un autre proxy ou DIRECT suit-il dans la liste ?
Demande d’authentification non prise en charge	Répétition de 407 ou invite de connexion	Le navigateur implémente-t-il le schéma demandé ?
Identifiant erroné ou expiré	407 après envoi de l’identifiant	La référence du secret a-t-elle été résolue et sa valeur expurgée des sorties ?
Échec du certificat du proxy HTTPS	Rejet de la connexion sécurisée au proxy	La validation du certificat reste-t-elle intacte ?
Le proxy ne peut pas résoudre la destination	Échec d’hôte ou de tunnel propre au proxy	Le client a-t-il évité de réessayer la destination en direct ?
CONNECT refusé	Échec de la navigation HTTPS vers cette destination	Le refus est-il traité comme une politique, non comme une autorisation de contournement ?
Fichier PAC indisponible	La résolution du proxy se bloque ou change de route	Le PAC est-il obligatoire ou Chromium peut-il utiliser silencieusement DIRECT ?
Motif de contournement trop large	Certains sites se connectent directement	Les règles exactes d’hôte, sous-domaine, port et implicites sont-elles comprises ?
WebRTC utilise une autre interface	Le chemin multimédia diffère du trafic de la page	L’UDP non acheminé par proxy est-il désactivé pour le profil ?
Une connexion existante survit à un changement	L’ancienne route reste temporairement active	Les connexions sont-elles vidées ou le profil redémarré ?
Capture de diagnostic trop détaillée	Des URL, noms d’hôtes ou secrets entrent dans un fichier d’assistance	Quel mode d’expurgation et quelle règle de conservation s’appliquent ?

Le repli de Chromium conserve un état. Un proxy victime d’une défaillance de connexion peut être marqué comme défaillant et placé temporairement après d’autres entrées. Si DIRECT figure dans la liste, les requêtes ultérieures peuvent sortir sans proxy. Un refus de CONNECT est traité différemment, car il peut représenter une politique intentionnelle de destination plutôt qu’un proxy indisponible.

L’échec du PAC exige une attention particulière. Chromium indique qu’un fichier PAC indisponible peut silencieusement revenir à une résolution directe, sauf si le PAC est obligatoire. La politique ProxySettings de Chrome expose précisément ProxyPacMandatory pour empêcher ce repli direct.

WebRTC et UDP nécessitent leur propre décision

Une page peut utiliser des chemins WebRTC qui ne correspondent pas aux requêtes URL HTTP et HTTPS ordinaires. La politique WebRtcIPHandling par défaut de Chrome peut utiliser toutes les interfaces disponibles. Son mode disable_non_proxied_udp limite WebRTC à TCP sur l’interface publique, sauf si un proxy configuré prend en charge UDP.

Cette politique est documentée au niveau du profil, ce qui la rend pertinente pour un proxy de profil, mais elle demeure un contrôle distinct. Elle peut réduire les performances multimédias ou rompre un flux exigeant l’UDP direct. Choisissez et testez explicitement ce compromis. Ne prétendez pas à un confinement complet par proxy sur la seule base d’un chargement de page réussi.

Choisir entre échec en mode fermé et disponibilité

Le repli direct peut être légitime pour un profil de navigation général qui privilégie la disponibilité. Il est dangereux pour un flux dont l’autorisation, la confidentialité ou la validité d’un test régional dépend d’un chemin de sortie précis.

Une bonne politique de profil nomme le comportement voulu :

• Proxy obligatoire : arrêter les requêtes réseau affectées lorsque le chemin sélectionné est inutilisable.
• Ensemble de proxys approuvés : n’essayer que des alternatives nommées soumises à une politique équivalente.
• Repli direct autorisé : afficher le changement de route et consigner l’événement sans valeurs secrètes.
• Contournement explicite : documenter la catégorie de destination et la raison de l’accès direct.

L’interface doit rendre l’état de la route visible avant le lancement et après une défaillance. Passer silencieusement du proxy au direct transforme une erreur réseau en erreur d’intégrité : le flux peut sembler réussir tout en utilisant le mauvais chemin.

Une matrice de validation sûre

Testez avec des extrémités et des zones DNS que vous possédez ou êtes autorisé à examiner. Consignez les résultats attendus avant le test.

1. Vérifiez que le schéma de proxy déclaré correspond au transport réel de l’extrémité.
2. Confirmez le fonctionnement requis de HTTP, HTTPS, WebSocket et WebRTC.
3. Observez l’adresse de sortie sur une destination contrôlée.
4. Observez quel résolveur reçoit la recherche de destination et lequel amorce le nom d’hôte du proxy.
5. Faites expirer un identifiant de test et confirmez qu’aucune valeur brute n’apparaît dans l’interface, les journaux ou les sorties d’automatisation.
6. Rendez le proxy de test inaccessible et confirmez le résultat configuré en mode fermé ou avec repli.
7. Refusez une destination CONNECT contrôlée et confirmez qu’un refus de politique ne devient pas un accès direct.
8. Rendez un PAC de test indisponible et confirmez le comportement obligatoire.
9. Exercez les cas de contournement exacts, de sous-domaines, locaux, link-local, IPv4 et IPv6 nécessaires au flux.
10. Modifiez le proxy pendant que des connexions sont actives et vérifiez quand la nouvelle route prend effet.
11. Ne capturez que le détail de diagnostic nécessaire au test, puis vérifiez sa conservation et sa suppression.

Les recommandations NetLog de Chromium traitent la journalisation réseau comme une question de confidentialité et de sécurité. Les modes expurgés peuvent omettre les champs sensibles, tandis que les modes détaillés peuvent contenir des cookies ou en-têtes d’authentification. Un fichier d’assistance doit être traité selon son mode de capture réel, pas selon son nom.