Proxys SOCKS5 et SOCKS4

Un proxy SOCKS permet à une application de demander à un serveur intermédiaire de se connecter à une destination pour elle. Le proxy ouvre la connexion demandée et transmet les données dans les deux sens. L’application continue d’utiliser son propre protocole : cela fonctionne donc pour les requêtes web, les clients API, les transferts de fichiers et d’autres logiciels prenant en charge SOCKS.

Pour une nouvelle configuration, SOCKS5 offre généralement les options les plus utiles : davantage de formats d’adresse, un choix de méthodes d’authentification et la prise en charge d’UDP. SOCKS4 reste utile pour les logiciels qui exigent l’ancienne version. Le choix plus général entre ces protocoles et les proxys HTTP est traité dans Proxys SOCKS ou HTTP.

Comment une application se connecte par SOCKS

Prenons une application qui ouvre https://example.com/ par un proxy SOCKS5. Elle atteint d’abord le proxy, lui demande d’ouvrir une connexion au site web, puis seulement échange les données du site. Le processus comporte quatre étapes :

1. L’application se connecte au nom d’hôte ou à l’IP du proxy et à son port d’écoute en TCP.
2. L’application et le proxy sélectionnent un mode d’accès. Si ce mode exige des identifiants, l’application les fournit et le proxy les vérifie.
3. L’application envoie une requête SOCKS CONNECT avec l’adresse et le port de destination. Le proxy vérifie ses règles d’accès, tente d’établir la connexion vers la destination et indique le résultat.
4. Après une réponse de réussite, l’application communique avec la destination par le proxy. Pour un site HTTPS, elle établit une connexion TLS avec le site et vérifie son certificat avant d’envoyer la requête web.

Les deux numéros de port appartiennent à des serveurs différents. Un proxy d’exemple peut écouter sur proxy.example:1080, tandis que le site web est atteint sur example.com:443. Le port 1080 est conventionnel pour SOCKS, mais un service peut en utiliser un autre. Utilisez le port d’écoute attribué à votre proxy ; il ne remplace pas le port de destination.

Pendant une transmission TCP ordinaire, SOCKS fait passer le flux d’octets de l’application sans devoir interpréter chaque requête HTTP ou commande de fichier. L’application continue de communiquer avec la destination dans son propre protocole. C’est pourquoi le même mécanisme de connexion SOCKS peut servir aux clients web et à d’autres types de logiciels.

CONNECT est une commande de SOCKS, avec son propre format de message ; elle diffère de la méthode HTTP CONNECT. SOCKS définit aussi BIND pour les applications qui ont besoin qu’un serveur se connecte en retour par le proxy, comme cela peut arriver avec FTP actif. BIND nécessite une prise en charge distincte et n’est pas utilisé pour une requête ordinaire à un site web ou à une API.

Ce qui change entre SOCKS4, SOCKS4a et SOCKS5

SOCKS4 ouvre des connexions TCP vers des adresses IPv4. SOCKS4a ajoute la possibilité d’envoyer un nom d’hôte, pour que le proxy puisse trouver son IP par DNS. SOCKS5 ajoute un choix de méthodes d’authentification, accepte les adresses IPv4, les adresses IPv6 et les noms d’hôte, et définit la transmission UDP.

Ce sont les possibilités du protocole. Le client et le service de proxys doivent implémenter la fonction précise que vous souhaitez utiliser. Par exemple, un service SOCKS5 peut gérer des connexions TCP sans offrir de relais UDP utilisable.

SOCKS5 peut transmettre une destination IPv6 dans sa requête, mais le proxy doit aussi pouvoir atteindre ce serveur IPv6. Les deux connexions peuvent utiliser des versions IP différentes : l’application peut atteindre le proxy en IPv4, tandis que le proxy se connecte à la destination en IPv6.

SOCKS4a est une extension de SOCKS4, et non un autre nom pour toute connexion SOCKS4. Si un ancien client n’envoie que des adresses IPv4, sélectionner SOCKS4 ne lui donne pas la résolution DNS distante. SOCKS4a doit être pris en charge aux deux extrémités. SOCKS5 est normalement le choix le plus simple lorsque les deux extrémités le prennent en charge ; sélectionner SOCKS4 n’améliore pas en soi la réputation ou la vitesse de l’IP de sortie.

Qui résout le nom de destination

Avant qu’une connexion puisse atteindre un serveur nommé, son nom doit être traduit en adresse IP. SOCKS5 peut accepter soit le résultat de cette résolution, soit le nom lui-même. Le paramètre DNS du client détermine ce qu’il envoie.

Avec le DNS local, l’application demande reports.example à son résolveur configuré. Supposons que la réponse soit 203.0.113.27 : l’application demande alors une connexion SOCKS vers 203.0.113.27:443. La résolution a déjà eu lieu côté client, même si la connexion ultérieure au site passe par le proxy.

Avec le DNS côté proxy, l’application envoie reports.example:443 sans résoudre d’abord cette destination localement. Le proxy obtient son IP par DNS et ouvre la connexion demandée. Le nom d’hôte parvient au proxy dans la requête SOCKS.

Cela peut aider lorsque le client ne peut pas résoudre un nom que le proxy parvient à résoudre. Certains services renvoient des adresses différentes selon le résolveur DNS ; déplacer la résolution peut donc changer le serveur qui reçoit la connexion. Cela ne définit pas le pays de sortie du proxy et ne garantit pas que le site acceptera la requête.

Dans curl, les deux commandes suivantes sélectionnent les deux modes DNS :

curl --proxy socks5://proxy.example:1080 https://example.com/
curl --proxy socks5h://proxy.example:1080 https://example.com/

socks5:// demande à curl de résoudre le nom du site localement ; socks5h:// le transmet au proxy. Les deux utilisent SOCKS5. Le h signifie que le proxy résout le nom d’hôte dans la syntaxe d’URL de ce client. Il ne transforme pas SOCKS5 en HTTPS et n’ajoute pas de chiffrement. D’autres applications peuvent utiliser une case à cocher ou choisir automatiquement le DNS distant. Remplacez le nom d’hôte et le port du proxy d’exemple par les informations de votre service et fournissez l’authentification requise.

Transmettre un nom de domaine dans une requête TCP SOCKS5 ne nécessite pas la prise en charge du relais UDP. Le proxy effectue la résolution avec sa propre configuration DNS. Cela diffère d’une demande à SOCKS5 de transporter les paquets UDP d’un client.

Si un client configuré pour laisser le DNS de destination au proxy effectue cette résolution localement, il expose le nom demandé en dehors du trajet prévu. C’est une fuite DNS. Le DNS chiffré protège l’échange avec le résolveur, mais celui-ci reçoit toujours le nom. Résoudre le nom d’hôte du proxy est une tâche distincte, et les autres applications conservent leur propre comportement DNS. Le DNS distant dans un programme ne déplace pas toutes les résolutions de l’appareil.

Authentification et chiffrement

SOCKS5 permet au client de proposer les méthodes d’authentification prises en charge et au proxy d’en choisir une. Le nom d’utilisateur et le mot de passe constituent une option. Une autre est la connexion sans échange d’identifiants SOCKS, qu’un service peut autoriser après avoir vérifié l’IP source du client dans une liste d’adresses autorisées. Un point de connexion sans champ de mot de passe peut donc tout de même restreindre l’accès.

L’absence d’accord sur une méthode diffère d’un mot de passe refusé : dans le premier cas, l’échange du mot de passe n’a pas eu lieu. Un client sans prise en charge du nom d’utilisateur et du mot de passe ne peut pas utiliser un point de connexion SOCKS5 exclusivement protégé par mot de passe simplement parce qu’il possède un paramètre SOCKS5. SOCKS4 comporte un champ d’identifiant utilisateur, mais aucun échange standard de mot de passe équivalent ; son serveur peut tout de même appliquer des règles d’accès.

L’échange habituel du nom d’utilisateur et du mot de passe SOCKS5 ne chiffre pas les identifiants. Il a lieu avant que l’application établisse HTTPS avec la destination ; cette connexion HTTPS ultérieure ne protège donc pas l’authentification proxy antérieure. Chiffrer le trajet entre client et proxy nécessite une connexion protégée distincte ou un mécanisme de sécurité explicitement pris en charge.

Pendant une transmission SOCKS ordinaire, HTTPS protège l’échange de l’application avec le site web, avec vérification des certificats activée et sans interception TLS. Un protocole applicatif non chiffré reste non chiffré à travers le relais. La seule prise en charge de SOCKS5 ou de l’authentification par mot de passe ne garantit pas un trafic chiffré.

Le proxy connaît toujours l’IP de connexion du client, la destination demandée et les horaires de connexion. La destination voit l’IP de sortie du proxy et reçoit les données applicatives qui lui sont destinées. Les cookies, les connexions aux comptes et d’autres identifiants applicatifs peuvent toujours identifier l’utilisateur ; changer de version SOCKS ne les supprime pas.

Comment SOCKS5 transporte TCP et UDP

TCP fournit un flux ordonné d’octets. Une requête de navigateur, un appel API ou une session SSH peut utiliser une connexion TCP SOCKS si le client prend en charge ce trajet et si le proxy autorise la destination. La réussite sur le port 443 d’un site web ne prouve pas que le port d’une autre application est disponible.

UDP envoie des datagrammes distincts. Un client SOCKS5 ouvre d’abord une connexion de contrôle TCP et demande un relais avec UDP ASSOCIATE. Le proxy renvoie l’adresse du relais et son port UDP. Le client y envoie ses datagrammes avec des en-têtes SOCKS décrivant leurs destinations. Fermer la connexion de contrôle TCP met fin à cette association UDP ; les datagrammes circulent séparément de la connexion de contrôle, et non dans un flux SOCKS CONNECT ordinaire.

L’application et le service doivent tous deux prendre en charge ce mécanisme, et le réseau doit autoriser le trajet UDP. Un programme peut réussir une connexion TCP alors que sa fonction vocale, de jeu ou autre utilisant UDP échoue encore. Une requête HTTPS réussie via SOCKS CONNECT démontre la transmission TCP, pas le fonctionnement d’UDP. QUIC utilise UDP, mais son bon fonctionnement dépend aussi du client et du trajet complet ; la seule mention SOCKS5 ne le garantit pas.

Quand SOCKS est utile

SOCKS est utile lorsqu’un logiciel a besoin d’une connexion intermédiaire tout en conservant son propre protocole applicatif. Un script peut demander des données API par une IP de sortie attribuée, un client de transfert de fichiers peut atteindre un serveur distant par un trajet approuvé, et une application de bureau compatible peut utiliser un proxy sans être un navigateur web. Chaque cas dépend de la prise en charge de SOCKS par le client et des ports de destination permis par le service.

Pour un travail répété avec le même compte ou le même serveur, une sortie fixe peut convenir. Pour des tâches distinctes, un service rotatif peut être utile. SOCKS4 et SOCKS5 ne déterminent pas ce comportement : le service détermine l’IP de sortie, son type de réseau, son éventuel partage avec d’autres clients et le moment où elle change. La version du protocole n’établit pas non plus de classement de vitesse ; la longueur du trajet, la charge du serveur et la bande passante disponible influent sur le résultat.

La prise en charge par le client peut être plus limitée que le protocole. L’implémentation SOCKS5 native de Chrome résout les noms de destination par le proxy, mais n’effectue pas l’authentification SOCKS5 par nom d’utilisateur et mot de passe et ne relaie pas UDP. Un point de connexion exclusivement protégé par mot de passe peut donc fonctionner dans curl et échouer avec ce paramètre natif du navigateur. Un adaptateur externe est un élément distinct de la connexion, avec ses propres possibilités.

Un proxy configuré dans un programme s’applique aux connexions prises en charge par ce programme. Il ne configure pas un outil de téléchargement ou un script distinct. De même, les paramètres proxy du système affectent les logiciels qui les utilisent. Lorsqu’un adaptateur redirige les connexions d’une application sans prise en charge native de SOCKS, son périmètre TCP, UDP et DNS compte. SOCKS n’assure pas la transmission ICMP ordinaire ; ping ne teste donc pas ce trajet proxy.

Paramètres de connexion et test utile

Commencez par l’adresse du proxy, le port d’écoute, la version SOCKS et le mode d’accès fournis pour le point de connexion. Un nombre comme 1080 n’identifie pas le protocole à lui seul. Sélectionnez SOCKS dans le client au lieu de saisir la même adresse dans un champ proxy réservé à HTTP.

Les identifiants proxy autorisent l’utilisation de l’intermédiaire ; les identifiants du compte web autorisent l’utilisation du site. Ils appartiennent à des paramètres différents. Dans curl, --proxy-user fournit les identifiants proxy, tandis que --user fournit ceux de la destination. Pour l’accès par IP, la liste des adresses autorisées doit correspondre à l’IP source du client vue par le proxy, qui peut changer lorsque le client change de réseau.

Choisissez le mode DNS souhaité, puis vérifiez les règles de contournement. Un proxy configuré peut être ignoré pour les destinations figurant dans une liste d’exclusions. Dans curl, NO_PROXY peut provoquer ce comportement ; --noproxy "" efface ces exclusions pour une exécution lorsque vous souhaitez volontairement tester le trajet proxy.

Testez depuis le programme qui effectuera réellement le travail. Un service de vérification d’IP, ou le journal d’un serveur de destination que vous contrôlez, peut montrer l’IP source de la requête. Comparez ce résultat à une requête directe. L’adresse utilisée pour atteindre le proxy et l’adresse de sortie vue par la destination ne sont pas nécessairement identiques.

Essayez ensuite la tâche réelle. Une IP modifiée montre le trajet de la requête testée, mais ne mesure pas tous les modes de transport et ne permet pas de savoir comment un autre site répondra. Testez UDP ou IPv6 séparément lorsque la tâche en a besoin, et évaluez le temps de réponse et la stabilité de connexion avec une charge de travail représentative.

Localiser une erreur selon son étape de connexion

Distinguez la connexion au proxy, l’obtention de l’accès, l’ouverture de la connexion à la destination et la réception de la réponse applicative. Ces étapes ont des causes d’échec différentes.

Si une connexion HTTPS vérifiée réussit et que le site renvoie une page de connexion, un CAPTCHA ou un refus d’accès, la connexion SOCKS a déjà acheminé cet échange. Examinez la réponse du site et le comportement de l’application. Si la requête affiche plutôt votre IP publique habituelle, vérifiez le proxy choisi et les règles de contournement de ce programme.