chrome.proxy, PAC et routage : comment une extension VPN agit sur le trafic du navigateur

Dossier technique

Une extension VPN dans Chrome ne “prend pas Internet en charge”. Elle agit sur les paramètres proxy du navigateur, donc sur une couche de routage bornée au trafic que Chrome lui permet de gouverner. Ce point est décisif : un changement de chemin pour les requêtes web du navigateur ne doit jamais être confondu avec une couverture système complète.

Dans Chromium, l’API chrome.proxy sert à gérer les paramètres proxy de Chrome. Le mot important n’est pas “proxy” mais “de Chrome”. Une extension qui s’appuie sur cette API agit sur la politique de sortie du navigateur, pas sur la pile réseau entière du poste. C’est la raison pour laquelle une extension VPN de navigateur peut modifier le trajet apparent des requêtes web sans devenir, pour autant, un équivalent fonctionnel d’un client VPN système.

La conséquence immédiate est simple : si l’on veut juger une extension VPN sérieusement, il faut comprendre sa couche d’action. Tant qu’on reste au niveau du symptôme visible — une IP qui change dans un site web, une interface qui affiche “connected”, une promesse de chiffrement — on ne lit pas la mécanique réelle. Ici, le sujet est le routage navigateur, ses modes, ses exceptions et ses limites.

Le proxy du navigateur n’est pas une abstraction neutre

Une extension qui utilise chrome.proxy n’“ajoute pas un tunnel” de façon magique. Elle manipule une configuration de proxy que Chrome applique ensuite à ses propres connexions. Cette différence de formulation compte. Le navigateur n’est pas l’OS, et son trafic n’est pas l’intégralité du trafic machine.

Dit autrement, l’extension n’obtient pas une souveraineté réseau globale ; elle obtient un levier sur la façon dont le navigateur résout son chemin de sortie. Ce levier peut être puissant dans son périmètre, mais il reste borné. C’est précisément pour cela que la distinction entre extension VPN et application VPN n’est pas un débat de confort, mais une question de couche technique.

Le droit d’agir sur le routage commence par la permission proxy

Une extension ne peut pas manipuler les paramètres proxy de Chrome sans déclarer la permission proxy. Ce n’est pas une simple formalité administrative. C’est le point d’entrée vers une capacité qui modifie concrètement le chemin de sortie du navigateur.

Cela signifie qu’une extension VPN centrée sur Chrome doit être lue d’abord comme un produit qui réclame le droit de gouverner les paramètres proxy du navigateur, puis seulement comme un outil de confidentialité. Tant qu’on ne part pas de là, on inverse l’ordre de lecture du produit.

{
  "name": "Example",
  "manifest_version": 3,
  "permissions": ["proxy"]
}

Pour la lecture détaillée du modèle de permissions, voir Permissions d’une extension VPN.

Les cinq modes de ProxyConfig ne décrivent pas la même logique de routage

Le cœur de chrome.proxy repose sur un objet ProxyConfig. Son champ mode détermine le comportement global de Chrome vis-à-vis du proxy. Ce choix n’est pas cosmétique : il définit si le navigateur doit sortir en direct, détecter automatiquement un proxy, exécuter une logique PAC, appliquer des serveurs fixes, ou s’aligner sur les paramètres système.

direct

En mode direct, Chrome crée ses connexions sans proxy. Une extension VPN qui prétend protéger la navigation ne peut évidemment pas rester dans ce mode si elle veut modifier le chemin de sortie. C’est le mode de non-intervention explicite.

auto_detect

En mode auto_detect, la configuration est déterminée par découverte automatique, typiquement via WPAD. Ce mode peut exister dans des environnements administrés, mais il n’est pas un mécanisme de contrôle fin propre à l’extension. Il délègue une partie de la logique à l’infrastructure de découverte.

pac_script

Le mode pac_script déporte la décision vers un script PAC. C’est le mode le plus intéressant quand on veut raisonner par politique : quelle URL doit passer par quel proxy, et dans quels cas faut-il sortir en direct ou choisir une autre route. Il ne dit pas seulement “utilise ce serveur”, mais “évalue une règle pour déterminer le chemin de sortie”.

fixed_servers

Le mode fixed_servers décrit une politique plus statique. On fournit des règles explicites, avec un proxy unique pour plusieurs protocoles ou une combinaison de proxyForHttp, proxyForHttps et fallbackProxy. C’est plus simple à lire qu’un PAC, mais moins expressif dès qu’on veut une logique conditionnelle.

system

Le mode system demande à Chrome d’utiliser les paramètres proxy du système d’exploitation. Il faut être précis ici : revenir au mode system n’est pas la même chose que n’avoir aucune configuration explicite. Chrome distingue les paramètres système, les options de ligne de commande, les réglages d’extensions et les policies. Le mot “système” ne veut donc pas dire “absence de gouvernance”.

fixed_servers : simple à déployer, vite limité

Le mode fixed_servers convient quand l’extension veut appliquer une politique de sortie relativement stable. Deux schémas dominent. Le premier repose sur singleProxy, qui applique le même proxy aux requêtes prises en charge. Le second repose sur des règles par protocole, avec un éventuel fallbackProxy pour ce qui n’est pas explicitement couvert.

Ce modèle est utile parce qu’il est lisible. Il permet de voir immédiatement si l’extension cherche une route unique ou une séparation par type de trafic. En revanche, dès qu’il faut une logique contextuelle, par hôte, par URL ou par scénario, la configuration fixe atteint rapidement ses limites.

{
  mode: "fixed_servers",
  rules: {
    singleProxy: {
      scheme: "socks5",
      host: "203.0.113.10",
      port: 1080
    },
    bypassList: ["localhost", "*.internal.example"]
  }
}

Il faut aussi lire correctement la présence d’un fallbackProxy. S’il est absent, le trafic non couvert par une règle spécifique peut sortir directement. C’est un point d’architecture, pas un détail de configuration.

pac_script : la politique de routage devient programmable

Le mode PAC change de nature. On ne décrit plus seulement un serveur de sortie ; on décrit une logique de décision. Un script PAC permet au navigateur d’évaluer, pour une URL et un hôte donnés, s’il faut utiliser un proxy, lequel, dans quel ordre, ou s’il faut sortir en direct. C’est là que l’on passe d’un routage statique à une politique de routage.

Cette expressivité a un coût. Un PAC mal conçu peut produire une politique opaque, difficile à auditer ou à maintenir. Il peut aussi multiplier les exceptions implicites et rendre plus difficile la compréhension réelle de la couverture. Une extension sérieuse devrait donc exposer clairement la logique qu’elle applique, ou au moins laisser comprendre pourquoi elle a choisi un PAC plutôt qu’une configuration fixe.

{
  mode: "pac_script",
  pacScript: {
    data: "function FindProxyForURL(url, host) {\n" +
          "  if (dnsDomainIs(host, '.corp.example')) return 'DIRECT';\n" +
          "  return 'SOCKS5 203.0.113.10:1080; DIRECT';\n" +
          "}"
  }
}

Le paramètre mandatory d’un objet PacScript mérite aussi l’attention. S’il est activé, un PAC invalide peut empêcher la pile réseau de retomber vers des connexions directes. C’est un choix de sûreté opérationnelle, pas un simple drapeau secondaire.

bypassList : l’exception est aussi une politique

Les listes d’exclusion sont souvent lues à la hâte. C’est une erreur. Un bypassList définit explicitement quels serveurs ou motifs d’hôtes doivent être joints sans proxy. En d’autres termes, il matérialise la part du trafic que l’extension choisit de ne pas envoyer vers son chemin de sortie principal.

Cette logique peut être légitime : accès locaux, hôtes internes, exceptions techniques, besoins de compatibilité. Mais elle doit être traitée comme une composante de la politique de routage, pas comme un appendice. Une extension qui annonce une protection uniforme tout en multipliant les contournements doit être lue avec plus de dureté.

Plus la liste d’exclusion est longue, plus la promesse implicite de couverture homogène devient fragile. Ici encore, on ne juge pas seulement le produit à son interface, mais à sa politique.

Le serveur de sortie n’est pas qu’une adresse : scheme, host et port comptent

Un objet ProxyServer décrit un proxy concret avec au minimum un hôte, et éventuellement un schéma et un port. Le schéma n’est pas décoratif. Il indique la nature du protocole utilisé pour joindre le proxy lui-même. Un même discours marketing sur “la connexion” peut donc masquer des choix d’implémentation très différents.

Pour un audit, cela signifie qu’il faut regarder ce qui est effectivement déclaré : schéma absent, schéma par défaut, usage de socks5, combinaison de règles fixes et de fallback, cohérence entre ce qui est promis et ce qui est paramétré.

Le point important n’est pas de fantasmer le champ scheme, mais de rappeler que la politique de sortie du navigateur n’est pas monolithique. Elle est composée d’objets réseau explicites.

Les paramètres effectifs ne dépendent pas toujours de l’extension seule

Une autre erreur fréquente consiste à croire qu’un appel à set() suffit à prouver qu’une extension contrôle effectivement le proxy. Chromium n’est pas aussi naïf. Les réglages du navigateur sont des ChromeSettings, avec une logique de couches, de scopes et de précédence.

Les paramètres système, les options de ligne de commande, les extensions et les policies peuvent tous influencer le résultat effectif. Les settings fournis par policy ont une précédence plus forte que ceux des extensions. Une extension peut donc “mettre” une configuration sans être, en pratique, l’acteur qui gouverne réellement le résultat final.

Une lecture technique correcte suppose donc de distinguer :

• ce que l’extension demande de configurer ;
• ce que Chrome accepte comme valeur ;
• ce qui reste effectivement appliqué après arbitrage avec les autres couches.

C’est la raison pour laquelle un produit qui affiche “connected” n’a pas encore prouvé qu’il détient le contrôle effectif du routage navigateur.

Les scopes regular, incognito_persistent et incognito_session_only changent aussi la lecture

Les paramètres proxy manipulés via le modèle ChromeSetting ne vivent pas dans un vide conceptuel. Chromium distingue plusieurs scopes. Le scope regular s’applique aux fenêtres normales et peut être hérité par les fenêtres privées si rien ne les surcharge. Les scopes incognito_persistent et incognito_session_only introduisent, eux, des comportements spécifiques aux fenêtres privées.

Cela compte pour une extension VPN parce que l’éditeur peut donner une impression de cohérence globale alors que la portée réelle dépend aussi de la façon dont les réglages ont été appliqués selon le contexte de navigation. Un audit sérieux doit donc regarder le mode de configuration et le scope dans lequel cette configuration est posée.

PAC contre règles fixes : le vrai choix est entre lisibilité et expressivité

Il serait paresseux de dire que le PAC est “plus avancé” et les règles fixes “plus simples”. La vraie opposition est ailleurs. Les règles fixes sont plus directement auditables : on voit vite quel proxy est utilisé et où se situent les exceptions. Le PAC, lui, permet d’exprimer une politique bien plus fine, mais au prix d’une complexité supérieure et d’une lisibilité plus faible si l’éditeur ne documente pas sa logique.

Dans un site technique, il faut donc refuser les conclusions automatiques. Une politique PAC n’est pas supérieure par essence. Une politique fixe n’est pas inférieure par nature. Le bon critère est la cohérence entre le besoin, la maintenabilité et la transparence du routage.

Les limites du routage navigateur doivent être rappelées sans relâche

Une extension qui route proprement le trafic du navigateur reste une extension qui route le trafic du navigateur. C’est une phrase volontairement répétitive, parce qu’elle doit résister aux réflexes marketing. Le fait qu’une politique proxy soit techniquement correcte dans Chrome ne dit rien, à lui seul, du comportement des autres applications du poste.

C’est précisément ici que naissent la plupart des surpromesses. Tant que l’on reste dans la couche navigateur, le raisonnement tient. Dès qu’on extrapole à l’ensemble du poste, on change d’objet sans le dire. Pour la partie strictement liée aux angles morts qui subsistent, voir Fuites et surface d’exposition.

Ce qu’il faut auditer dans la politique de routage d’une extension VPN

• Le mode réellement utilisé : fixed_servers, pac_script, system, ou autre.
• La présence d’un fallbackProxy et ses implications.
• L’existence d’un bypassList et l’étendue réelle des exceptions.
• La cohérence entre le schéma du proxy, le discours de l’éditeur et l’architecture annoncée.
• Le scope de configuration utilisé pour les fenêtres normales et privées.
• Le contrôle effectif obtenu par l’extension face aux autres couches de configuration.
• La lisibilité et l’auditabilité d’un éventuel script PAC.
• L’écart entre “connexion affichée” et routage effectivement gouverné.

Cette lecture doit ensuite être rapprochée de la méthode d’audit complète et, pour la mécanique des permissions, de la page dédiée au manifeste et aux accès déclarés.

Conclusion

chrome.proxy donne à une extension un levier réel sur les paramètres proxy de Chrome, donc sur le routage du navigateur. Ce levier peut être simple, programmatique, partiel, conditionnel, ou encadré par d’autres couches de configuration. Il ne doit jamais être relu comme une preuve automatique de couverture système. Une extension VPN sérieuse s’évalue donc d’abord comme une politique de routage navigateur, ensuite seulement comme une promesse de confidentialité.