Choisir une extension de proxy pour navigateur : protocole, périmètre et auto-tests

Les extensions de proxy pour navigateur ont une limite souvent oubliée : elles ne prennent en charge que les requêtes émises par le navigateur. Les mises à jour système, les clients de bureau et les autres applications continuent de passer par la route d'origine. Réfléchissez d'abord précisément à ce que vous voulez faire passer par le proxy, puis choisissez l'outil : vous vous épargnerez beaucoup de diagnostics par la suite.

Commencer par classer selon trois usages

Le besoin le plus courant est la commutation par site : faire passer quelques domaines par le proxy et laisser tout le reste en direct. Ce cas de figure repose sur une liste de règles, et l'intérêt de l'extension réside dans la rapidité du basculement et la répartition par domaine.

Le deuxième type est le proxy global, où tout le trafic du navigateur sort par un seul point de sortie. Le réglage est le plus simple, mais le prix est immédiat : si la sortie tombe, le navigateur est pratiquement hors ligne, ce qui rend l'usage quotidien instable.

Le troisième type est lié à un environnement : chaque profil de navigateur est fixé à une sortie et les profils ne s'influencent pas mutuellement. C'est l'approche retenue lorsqu'on gère plusieurs comptes ou plusieurs projets en parallèle ; l'extension n'est ici qu'un complément, car la sortie elle-même est généralement configurée à un niveau plus bas.

Ce qu'il faut examiner pour évaluer une extension

La prise en charge des protocoles vient en premier. Les proxys HTTP et HTTPS ne traitent que le TCP, tandis que SOCKS5 est plus général, mais sa prise en charge de l'UDP dépend de l'implémentation, et beaucoup d'extensions laissent passer l'UDP tel quel ou le suppriment purement et simplement. Ce point comptera plus loin, car il est directement lié aux fuites WebRTC.

Il faut examiner de près le mode d'authentification. L'authentification par nom d'utilisateur et mot de passe est pratique, mais les identifiants enregistrés dans l'extension restent en local en clair ou faiblement chiffrés, et peuvent donc être lus par quiconque utilise l'ordinateur ; l'authentification par liste blanche d'IP ne stocke rien dans l'extension, au prix d'une remise à jour de la liste à chaque changement de réseau.

Le périmètre est le point qui pose le plus souvent problème. En mode règles, les domaines qui ne correspondent à aucune règle partent par défaut en direct, et vous ne savez pas forcément quels domaines la page demande réellement. Une fois la connexion établie avec un site HTTPS, l'extension ne voit que le domaine, pas le chemin précis : l'idée d'une répartition par chemin est donc pratiquement inapplicable.

Pensez aussi à l'étendue des permissions. Si une extension de proxy demande en plus l'accès aux données de tous les sites, aux informations des onglets ou au presse-papiers, demandez-vous si ces permissions ont un rapport avec la fonction annoncée. Les montées de version du manifeste des extensions de navigateur resserrent également les interfaces disponibles, ce qui a contraint certaines extensions anciennes à revoir leur architecture.

Pour l'activité de maintenance, ne regardez pas le nombre d'entrées du journal des modifications, mais si quelqu'un suit les évolutions en amont. Parmi les extensions de proxy, la version boutique de Proxy SwitchyOmega a été retirée et un fork maintenu par la communauté (notamment la lignée ZeroOmega) a repris les adaptations ; des extensions comme FoxyProxy existent sur plusieurs navigateurs. Ces exemples sont neutres : le choix dépend toujours des points ci-dessus.

Le trafic qu'elle ne couvre pas

Une fois l'extension installée, le navigateur passe bien par le proxy, mais d'autres programmes du même ordinateur, les services de mise à jour en arrière-plan et certains flux internes au navigateur qui ne suivent pas le chemin de requête de l'extension peuvent encore sortir par la machine locale. Vérifier la cohérence du réseau ne peut pas se limiter au panneau de l'extension. Pour une isolation complète, il faut agir au niveau du proxy système ou à un niveau supérieur.

Auto-tests : d'abord la sortie, ensuite les fuites

Première étape : vérifier l'IP de sortie. Ouvrez quelques pages qui renvoient l'IP du visiteur et sa localisation, testez une fois dans une fenêtre normale et une fois dans un onglet correspondant à vos règles, puis comparez les résultats. Si une règle indique un proxy et que vous obtenez toujours l'adresse locale, c'est que la règle ne s'applique pas ou que le domaine ne correspond pas. Multiplier les sites permet de repérer les cas où seule une partie des requêtes passe par le proxy.

Deuxième étape : vérifier WebRTC. Des pages de test dédiées listent les adresses candidates locales et publiques obtenues par le navigateur ; si les candidates publiques affichent votre IP réelle au lieu de la sortie du proxy, l'UDP ne passe pas par le proxy et les scripts de la page peuvent encore déterminer votre position réseau réelle.

Troisième étape : vérifier le DNS. Si la localisation du résolveur DNS est très éloignée de celle de la sortie, certains sites considéreront l'environnement comme anormal.

La dernière étape consiste à refaire le test en fenêtre de navigation privée. Beaucoup d'extensions ne sont pas actives en navigation privée par défaut et doivent être autorisées manuellement dans leurs réglages ; oublier cette étape conduit à des conclusions totalement erronées.

Décider de l'usage après les tests

Les résultats des auto-tests sont plus fiables que la documentation d'une extension. Une fois alignés la sortie réelle, la localisation de la résolution DNS et l'exposition WebRTC, décidez s'il faut continuer avec l'extension ou déplacer la sortie à un niveau plus bas. Dans les scénarios à environnements multiples, il vaut mieux attribuer à chaque environnement une sortie dédiée et fixe, plutôt que de faire partager une seule sortie à plusieurs machines.