Enchaînement de proxys : comment ça marche et dans quels cas est-ce utile ?

Avertissement : nous sommes Geonode et nous vendons des proxys ; cet article nous amène donc à nous prononcer contre l’utilisation de notre propre produit. Enchaîner nos proxys derrière ceux d’un tiers, ou en passant par plusieurs des nôtres à la suite, ralentira vos requêtes, les rendra moins fiables et n’améliorera pas significativement votre situation. La raison est d’ordre structurel plutôt qu’une limitation propre à un fournisseur en particulier, et elle est expliquée ci-dessous. Il existe deux ou trois raisons réellement valables de recourir au chaînage, et elles concernent davantage le routage et l’accès que l’anonymat. Si votre objectif est l’anonymat, la réponse honnête est qu’un système spécialement conçu à cet effet y parvient correctement, contrairement à une pile de proxys commerciaux.

Qu'est-ce que le « chaînage » exactement ?

En temps normal : vous vous connectez à un proxy, puis le proxy se connecte à la destination. Deux connexions, un intermédiaire.

En chaîne : vous vous connectez au proxy A, qui se connecte au proxy B, qui se connecte à la destination. À chaque saut, la connexion précédente est interrompue et une nouvelle est établie ; ainsi, la destination ne voit que l'adresse du proxy B, et le proxy B ne voit que celle du proxy A.

Les avantages invoqués sont les suivants : aucun intermédiaire ne connaît les deux extrémités, et le traçage du chemin nécessite la coopération de tous les opérateurs de la chaîne.

Ces deux affirmations sont vraies au sens strict, mais elles s’avèrent en réalité bien moins solides dans la pratique que ne le laisse entendre ce résumé. La suite de cet article explique pourquoi.

Les deux façons de créer une chaîne

Le chaînage côté client est le cas le plus courant : votre machine est configurée pour acheminer le trafic via A, et A est configuré — ou programmé — pour le transmettre à son tour vers B. Des outils comme proxychains y parviennent en interceptant les connexions et en les faisant passer par une liste que vous contrôlez.

La caractéristique essentielle : c’est vous qui choisissez la chaîne. Vous connaissez chaque étape, vous pouvez les modifier, et aucun opérateur n’a besoin de coopérer. C’est pourquoi la quasi-totalité des chaînages pratiques se font côté client.

Le chaînage côté serveur consiste, pour un fournisseur, à acheminer votre trafic via une infrastructure que vous ne contrôlez pas. Certains services procèdent ainsi en interne : une passerelle qui met fin à votre connexion et la fait sortir par l’un de ses nombreux points de terminaison constitue techniquement une chaîne, bien qu’elle ne soit généralement pas décrite comme telle.

La caractéristique qui importe ici est l’inverse : vous ne contrôlez pas la chaîne et ne pouvez pas la vérifier. L’affirmation d’un fournisseur selon laquelle il achemine le trafic à travers plusieurs pays est invérifiable de votre côté. Il s’agit d’une déclaration de confiance, et non d’une architecture.

proxychains : son fonctionnement et ses limites

C'est l'outil le plus connu, et sa propre description explique clairement son fonctionnement. proxychains est « un programme UNIX qui intercepte les fonctions libc liées au réseau dans les programmes liés dynamiquement via une DLL préchargée et redirige les connexions via des proxys SOCKS4a/5 ou HTTP ».

Cette phrase résume à la fois son ingéniosité et sa limite.

L’ingéniosité : il fonctionne avec des programmes qui ne prennent pas en charge les proxys de manière native. Comme il intercepte les appels au niveau de la libc, une application effectuant des appels de socket classiques est redirigée de manière transparente, sans s’en rendre compte.

La limite, pour le dire clairement : il « ne fonctionne que sur les programmes liés dynamiquement » et nécessite que proxychains et l’application cible « utilisent le même lieur dynamique ». Les binaires liés statiquement — ce qui inclut une grande partie des logiciels Go modernes — ne sont tout simplement pas concernés. Le programme s’exécute, se connecte directement, et rien ne vous alerte.

Trois modes de chaîne sont pris en charge :

Ordre exact — les proxys sont utilisés exactement comme configurés. Ce mode est prévisible, mais un seul proxy inactif rompt la chaîne. Ordre dynamique — les proxys inactifs sont exclus de manière intelligente, ce qui permet à la chaîne de survivre aux défaillances, au prix de ne pas correspondre à la chaîne que vous avez spécifiée. Ordre aléatoire — un sous-ensemble aléatoire d’une longueur configurée, utile lorsque vous souhaitez varier la configuration d’une exécution à l’autre.

Les protocoles pris en charge sont SOCKS4, SOCKS4a, SOCKS5 et HTTP(S), avec une authentification par nom d’utilisateur/mot de passe pour SOCKS et une authentification de base pour HTTP.

Il existe également un mode de défaillance documenté qu’il convient de connaître car il est véritablement obscur : « lorsqu’un processus se divise, effectue une requête DNS dans le processus fils, puis utilise l’adresse IP du processus père, le mappage d’adresse IP correspondant ne sera pas trouvé. » Les applications structurées de cette manière présentent des comportements anormaux qui ressemblent à des problèmes réseau, mais qui n’en sont pas.

Les latences s'accumulent et la fiabilité diminue d'autant

Le calcul mathématique constitue l'argument le plus convaincant contre l'enchaînement aléatoire.

Les latences s'additionnent. Chaque saut ajoute son propre temps aller-retour ainsi que le temps de traitement. Une requête directe de 50 ms peut passer à 200 ms en passant par un proxy et à 400 ms en passant par deux. Pour une utilisation interactive, cela fait la différence entre une expérience utilisable et une expérience agaçante. Pour une tâche de scraping générant cent mille requêtes, cela fait la différence entre quatre heures et huit heures.

La fiabilité se multiplie, et la multiplication de nombres inférieurs à un ne peut aller que dans un sens. Si chaque saut est disponible indépendamment 95 % du temps :

Une chaîne de trois proxys fiables individuellement est un système qui échoue une requête sur sept. Et les défaillances dans une chaîne sont plus graves que celles sur un seul saut, car le diagnostic est plus difficile : un délai d’expiration indique que la chaîne s’est rompue, mais pas quel maillon est en cause.

La bande passante est facturée par saut. Si vous payez pour deux proxys facturés au volume, chaque octet est facturé deux fois. Enchaîner deux services résidentiels à 0,79 $/Go revient à 1,58 $/Go pour les mêmes données.

Le débit est limité par le saut le plus lent, et ajouter des sauts augmente les risques de ralentissement.

Face à ces coûts, l’avantage doit être substantiel. Ce n’est généralement pas le cas.

Le chaînage renforce-t-il votre anonymat ?

La réponse honnête est : moins qu’on ne le prétend, et cela dépend entièrement de l’identité des opérateurs.

Ce que permet réellement le chaînage. Aucun nœud ne voit à la fois votre adresse et celle de la destination. Le nœud A sait qui vous êtes et que vous avez communiqué avec B. Le nœud B sait qu’il a communiqué avec la destination, mais ignore qui en est à l’origine. C’est là une propriété réelle.

Pourquoi cela n’est pas aussi efficace qu’il n’y paraît.

La corrélation entre les relais est facile pour quiconque surveille les deux. Un observateur ayant une visibilité sur les deux extrémités — timing, volume, schémas — peut les relier sans rien déchiffrer. Il s’agit d’analyse de trafic, et c’est le problème central des systèmes d’anonymat. Deux proxys commerciaux ne le résolvent pas.

La propriété commune réduit la chaîne à néant. Si les deux sauts appartiennent au même fournisseur, ou revendent le même réseau sous-jacent, la séparation est imaginaire. Les relations de revente sur le marché des proxys sont courantes et ne sont pas toujours divulguées ; une chaîne passant par deux marques partageant un même fournisseur n’a qu’un seul opérateur, et non deux.

La couche applicative contourne complètement ce système. Les cookies, les identifiants de connexion, les empreintes de navigateur et tout ce que vous tapez vous identifient, quel que soit le routage. Une chaîne de cinq proxys acheminant une session où vous êtes connecté est un moyen très lent d’être identifié.

Les relevés de paiement et de compte permettent de remonter jusqu’à vous. Vous avez acheté ces services. Il en existe une trace.

Le chiffrement n’est pas multicouche. Dans une chaîne de proxys simple, chaque nœud peut lire tout ce qui n’est pas protégé par TLS. Le chaînage n’ajoute pas de chiffrement ; il ajoute des intermédiaires susceptibles de lire votre trafic. C’est le contraire de l’objectif recherché, et c’est précisément ce que traite la section suivante.

Tor : un enchaînement bien conçu

Il est utile de le considérer comme un modèle de référence, car il met en évidence ce qui manque à une pile de proxys commerciaux.

Le projet Tor explique clairement la différence : « Contrairement aux serveurs proxy classiques, qui créent un point unique de confiance et de défaillance, Tor achemine votre trafic via plusieurs relais avec un chiffrement en couches. »

Le trafic transite par au moins trois relais, et les informations sont délibérément fragmentées. Le premier relais peut constater qu’une adresse utilise Tor, mais ne peut pas déterminer la destination. Le relais intermédiaire voit le trafic chiffré et ne peut identifier ni l’expéditeur ni la destination finale. Le relais de sortie voit le trafic sortant mais pas sa source — et avec HTTPS, seul le site de destination est visible, et non le contenu.

Trois caractéristiques de conception permettent ce fonctionnement, et une chaîne de proxys manuelle n’en possède aucune :

Le chiffrement par couches. Chaque relais enlève une couche. Un relais ne peut pas lire ce que le relais suivant recevra. Dans une chaîne de proxys classique, chaque relais voit votre trafic tel que votre client l’a envoyé.

Les circuits sont sélectionnés par le client à partir d’un répertoire publié, avec des contraintes de chemin conçues pour éviter les relais corrélés. Dans une chaîne manuelle, vous choisissez parmi ce que vous avez acheté, et vous ne pouvez pas savoir si deux fournisseurs partagent une infrastructure.

Les relais sont gérés de manière indépendante par des bénévoles. Les fournisseurs de proxys commerciaux sont des entreprises soumises à des obligations en matière d’archivage, de facturation et de droit.

Rien de tout cela ne fait de Tor une solution universelle : il est lent, de nombreux sites le bloquent et il n’est pas adapté à la collecte de données à haut débit. Le propos est comparatif : si l’anonymat est votre objectif, un système conçu à cet effet fait l’affaire, tandis que l’empilement de proxys commerciaux en reproduit la forme sans en avoir la substance.

Les fuites qui compromettent toute la chaîne

Une chaîne est aussi solide que son maillon le plus faible, et plusieurs chemins la contournent complètement.

DNS. Le cas le plus courant. Si votre résolveur est interrogé directement, votre FAI voit tous les noms d’hôtes tandis que votre trafic passe par trois sauts. Avec SOCKS5, utilisez le schéma socks5h afin que les noms d’hôte soient résolus par le proxy plutôt que localement — la différence entre socks5:// et socks5h:// dans curl réside précisément là, et c’est le détail le plus souvent négligé dans la configuration d’un proxy.

WebRTC. Dans les navigateurs, il peut exposer des adresses locales et publiques en dehors du chemin du proxy.

IPv6. Une chaîne exclusivement IPv4 disposant d’une connectivité IPv6 signifie qu’une partie du trafic passe directement. De manière silencieuse et invisible, à moins d’être testée.

Binaires liés statiquement sous proxychains. Comme indiqué ci-dessus : l’interception ne s’applique tout simplement pas, et le programme se connecte directement sans avertissement.

Tout ce qui se trouve en dehors du processus intercepté. Mise à jour du système, télémétrie, services en arrière-plan. Ils n’ont jamais fait partie de la chaîne.

Règle générale : mieux vaut vérifier que supposer. Vérifier qu’un site web signale une adresse IP étrangère ne fait que confirmer ce qui allait manifestement changer. Notre guide sur les tests de proxys explique comment vérifier correctement le DNS, le WebRTC et l’IPv6 ; pour une chaîne, cette vérification est d’autant plus importante qu’il existe davantage de points de défaillance potentiels.

Raisons légitimes d'utiliser le chaînage

Des cas réels, dont aucun ne concerne l'anonymat.

Accéder à un réseau auquel vous ne pouvez pas accéder directement. Un proxy d'entreprise est votre seule voie de sortie, et vous avez besoin d'un deuxième proxy au-delà de celui-ci pour atteindre une destination spécifique. Il s’agit là d’un enchaînement de type « plomberie », et c’est de loin l’utilisation légitime la plus courante.

Pont de protocole. Votre application ne prend en charge que le protocole SOCKS, mais le proxy dont vous disposez utilise le protocole HTTP, ou inversement. Un proxy local effectue la conversion et le transfert. Encore une fois, de la « plomberie ».

Ajouter des fonctionnalités à un nœud local. Exécuter un proxy local pour la mise en cache, la journalisation, la réécriture des requêtes ou l’inspection TLS, qui transfère ensuite vers un proxy en amont. Il s’agit d’une chaîne dont le premier nœud existe pour effectuer une tâche plutôt que pour dissimuler quoi que ce soit, et c’est une pratique courante en développement et en test.

Routage géographique impossible à acheter directement. Il arrive parfois que l’emplacement de sortie dont vous avez besoin ne soit accessible que via un intermédiaire. C’est rare, et il vaut la peine de vérifier si un fournisseur propose simplement cet emplacement avant de construire une chaîne.

Tester le comportement multi-sauts. Si vous développez une application destinée à fonctionner derrière plusieurs proxys, il est légitime de tester ce chemin.

Remarquez ce que ces cas ont en commun : la chaîne existe en raison d’une contrainte de routage, et non parce qu’on a supposé qu’un plus grand nombre de sauts serait préférable. C’est cette distinction qu’il convient d’appliquer à votre propre cas.

Questions fréquentes

Le chaînage de proxys renforce-t-il l’anonymat ?

Légèrement, et moins que prévu. Cela signifie qu’aucun relais ne voit à la fois votre adresse et celle de la destination. Cela ne protège toutefois pas contre la corrélation du trafic, la propriété commune entre fournisseurs, ni l’identification au niveau de la couche application via les cookies, les identifiants de connexion et l’empreinte numérique. Le simple enchaînement n’ajoute en outre aucun chiffrement : chaque relais voit tout ce que le protocole TLS ne protège pas.

Combien de proxys dois-je enchaîner ?

Pour des raisons de routage légitimes, aussi peu que les contraintes l’exigent — généralement deux. Pour l’anonymat, enchaîner des proxys commerciaux n’est pas la bonne approche, quel que soit leur nombre, et un système conçu à cet effet s’en charge mieux. Chaque saut supplémentaire ajoute de la latence, multiplie la probabilité de défaillance et double votre facture de bande passante.

Qu’est-ce que proxychains et comment fonctionne-t-il ?

Il s’agit d’un outil Unix qui intercepte les fonctions libc liées au réseau dans les programmes liés dynamiquement et redirige les connexions via des proxys SOCKS4a/5 ou HTTP. Il offre un ordre de chaînage précis, dynamique et aléatoire. Sa principale limitation est qu’il ne fonctionne que sur les programmes liés dynamiquement — les binaires liés statiquement se connectent directement sans avertissement.

Le chaînage de proxys est-il lent ?

Oui, inévitablement. Chaque saut ajoute un aller-retour et un temps de traitement ; ainsi, une chaîne à deux sauts double approximativement le coût d’un seul proxy. Le débit est limité par le saut le plus lent, et si chaque saut est fiable à 95 %, une chaîne à trois sauts réussit environ 86 % du temps.

Puis-je enchaîner un VPN et un proxy ?

Techniquement oui, et c’est courant. En pratique, cela se traduit généralement par une latence accrue pour un changement modeste de ce que chaque partie observe. Votre fournisseur de VPN voit toujours que vous vous connectez, l’opérateur du proxy voit toujours vos requêtes, et aucune de ces deux configurations ne résout le problème de l’identification au niveau de la couche application.

Le chaînage empêche-t-il les sites web de me suivre ?

Non. Le suivi s’effectue via les cookies, les empreintes de navigateur, les identifiants de compte et les modèles comportementaux — aucun de ces éléments n’est affecté par le nombre de sauts réseau que votre trafic effectue. Le routage modifie l’adresse enregistrée par un site, et les sites ont cessé depuis longtemps de se fier uniquement à l’adresse.

Tor est-il une chaîne de proxys ?

Il s’agit d’un enchaînement doté de trois propriétés qui font défaut à une chaîne manuelle : un chiffrement en couches afin qu’aucun relais ne puisse lire ce que reçoit le suivant, des chemins sélectionnés par le client à partir d’un répertoire publié avec des contraintes visant à éviter les relais corrélés, et des relais bénévoles exploités de manière indépendante. Le projet Tor oppose cela aux proxys classiques, qui « créent un point unique de confiance et de défaillance ».

Dois-je payer deux fois la bande passante dans une chaîne ?

Si les deux relais sont facturés au volume, oui : chaque octet traverse les deux et est facturé par chacun d’eux. Deux services résidentiels à 0,79 $/Go coûtent 1,58 $/Go pour les mêmes données. C’est une raison évidente de vérifier si une chaîne résout réellement un problème avant d’en créer une.

Conclusion

Le chaînage de proxys est une technique de routage souvent présentée comme une technique de protection de la vie privée, alors que ces deux concepts ne sont pas identiques.

En tant que technique de routage, elle est parfois tout à fait indiquée : pour sortir via un proxy d’entreprise vers une destination nécessitant un autre proxy, pour faire le pont entre SOCKS et HTTP, ou pour placer un proxy local en amont à des fins de mise en cache et de journalisation. Dans ces cas-là, la chaîne existe en raison d’une contrainte, et la latence supplémentaire est le prix à payer pour cet itinéraire.

En tant que mesure de confidentialité, il s’agit d’une version affaiblie d’un concept qui existe sous une forme plus efficace. Une chaîne manuelle n’ajoute aucun chiffrement ; chaque saut peut donc lire tout ce que le protocole TLS ne protège pas. Elle ne permet pas de savoir si deux fournisseurs partagent une infrastructure. Elle n’apporte aucune protection contre la corrélation du trafic, ni contre les cookies, les identifiants de connexion et les empreintes numériques — qui constituent en réalité les véritables moyens d’identification.

Les coûts, quant à eux, sont certains. La latence s’accroît, la fiabilité diminue de manière exponentielle, et la bande passante facturée au volume coûte deux fois plus cher. Si vous envisagez de mettre en place une chaîne, la question pertinente est de savoir quelle contrainte de routage spécifique elle résout. Si la réponse est « plus il y a de sauts, plus cela semble sûr », les chiffres jouent en votre défaveur.