Méthodes d'authentification SOCKS5 (RFC 1929)

SOCKS5 (défini dans RFC 1928) ne suppose pas de méthode d'authentification — il négocie une. Dès que la connexion TCP au proxy s'ouvre, le client envoie un message de bienvenue listant les méthodes d'authentification qu'il prend en charge, et le proxy en choisit une.

Le message de bienvenue du client est : un octet de version (0x05), un compte de méthodes, puis autant d'identifiants de méthode. Les méthodes courantes sont 0x00 "aucune authentification requise", 0x02 "nom d'utilisateur/mot de passe", et 0xFF "aucunes méthodes acceptables". Le serveur répond avec deux octets : la version et la méthode unique qu'il a choisie. S'il renvoie 0x00, vous vous connectez immédiatement ; s'il renvoie 0x02, le client doit maintenant exécuter la sous-négociation nom d'utilisateur/mot de passe avant de pouvoir émettre une demande de connexion. Si le serveur renvoie 0xFF, aucune des méthodes proposées n'était acceptable et il ferme la connexion. C'est pourquoi un proxy SOCKS5 authentifié s4m SOCKS5 proxy sur le port 1080 s'attend à ce que votre client propose la méthode 0x02.

La méthode nom d'utilisateur/mot de passe (0x02) est spécifiée séparément dans RFC 1929. C'est un échange minuscule et autonome qui se produit après la négociation de méthode et avant la demande SOCKS :

• Le client envoie : un octet de version de sous-négociation (0x01 — notez que c'est la version d'authentification, pas la version SOCKS), un octet de longueur du nom d'utilisateur, le nom d'utilisateur, un octet de longueur du mot de passe, et le mot de passe.
• Le serveur répond avec deux octets : la version (0x01) et un octet d'état. 0x00 signifie succès ; tout autre chose signifie échec, et le serveur ferme la connexion.

Ce n'est qu'après un état de succès que le client procède à la demande CONNECT SOCKS5 réelle en nommant la destination. Comme le nom d'utilisateur et le mot de passe sont préfixés par leur longueur en un seul octet, chacun est limité à 255 octets. Consultez notre guide d'authentification proxy pour voir comment cela se passe avec de vrais clients et l'API pour la gestion des identifiants.

Le point critique et honnête : le RFC 1929 transmet le nom d'utilisateur et le mot de passe en texte clair. Les octets ne sont ni chiffrés ni hachés — quiconque peut observer la connexion TCP entre vous et le proxy peut lire vos identifiants. Le RFC lui-même reconnaît cela et avertit que la méthode n'est appropriée que lorsque cette exposition est acceptable.

Ce que cela signifie en pratique : la sécurité de l'authentification par nom d'utilisateur/mot de passe SOCKS5 dépend de la confiance dans le chemin vers le proxy, ou de l'encapsulation de l'ensemble de la connexion SOCKS dans quelque chose de chiffré. Les mesures d'atténuation que les gens utilisent incluent le tunnelage SOCKS5 sur TLS ou SSH, l'exécution du proxy sur un réseau de confiance, ou la dépendance à la liste blanche d'IP au lieu de (ou en plus de) l'utilisation d'identifiants — ce qu'une IP dédiée rend pratique. D'autres méthodes d'authentification SOCKS5 existent en principe (par exemple GSS-API du RFC 1928), mais le nom d'utilisateur/mot de passe reste de loin le plus largement implémenté, donc comprendre sa nature en texte clair — et ne pas réutiliser un mot de passe important comme identifiant de proxy — est important.