En SOCKS5, l'authentification ne se fait pas via un en-tête comme avec un proxy HTTP, mais par une sous-négociation distincte . Cette différence explique aussi pourquoi les messages d'erreur sont si peu explicites : lorsqu'une mauvaise méthode est proposée, le serveur ne renvoie aucun texte descriptif, il envoie un seul octet et ferme la connexion.
Négociation de méthode
Chaque étape représente quelques octets unidirectionnels. Si la négociation échoue, le serveur renvoie 0xFF ou 0x01 0x01 puis ferme la connexion — sans aucun texte d'erreur explicatif.
Méthodes prises en charge
| Code | Méthode | Utilisation |
|---|---|---|
0x00 | Aucune authentification requise | Serveurs protégés par whitelist d'IP |
0x01 | GSSAPI | Environnements Kerberos d'entreprise (rare) |
0x02 | Nom d'utilisateur / mot de passe | La méthode commerciale la plus répandue |
0xFF | Aucune méthode acceptable | Réponse de refus du serveur |
Le nom d'utilisateur et le mot de passe en clair sont envoyés. SOCKS5 n'assure aucun chiffrement par lui-même. Si vous l'utilisez sur un réseau non fiable, vos identifiants peuvent être lus ; dans ce cas, travailler via un tunnel SSH est plus sûr.
Problèmes fréquents
La ligne relative au navigateur est importante : de nombreux navigateurs ne prennent pas en charge l'authentification SOCKS5 depuis leur interface. Dans ce cas, un relais local portant les identifiants est nécessaire.
Le problème des navigateurs et sa solution
La prise en charge de l'authentification SOCKS5 par Chrome et Firefox est limitée, voire inexistante. Il existe deux solutions pratiques :
Passez à la whitelist d'IP
Si votre fournisseur la prend en charge, c'est la solution la plus propre : aucun identifiant n'est transmis et le navigateur fonctionne sans problème.
Installez un relais local
Exécutez sur la machine un petit proxy portant les identifiants, puis déclarez-le 127.0.0.1 au navigateur. Nous détaillons la méthode dans notre article sur le chaînage .
Configuration par bibliothèque
Si votre mot de passe contient @, : ou / , utilisez un champ distinct plutôt que le format URL ; sinon, vous devrez appliquer un encodage pourcent.
Comparaison avec la whitelist
En SOCKS5 aussi, les deux modèles sont valables et les critères de choix sont les mêmes qu'avec un proxy HTTP. Pour une comparaison détaillée, vous pouvez consulter notre article sur les méthodes d'authentification . La seule différence propre à SOCKS5 est le problème de prise en charge par les navigateurs : la whitelist le supprime entièrement.
Vérification
Tester délibérément avec un mot de passe erroné vous permettra de reconnaître plus facilement le message d'erreur le jour où vous rencontrerez un vrai problème.
Résumé
L'authentification SOCKS5 s'effectue par une sous-négociation distincte et ses messages d'erreur ne sont pas explicites. Les deux problèmes les plus fréquents sont un client qui ne propose jamais la méthode d'authentification et des navigateurs qui ne la prennent pas en charge. Comme les identifiants sont envoyés en clair, soyez prudent sur les réseaux non fiables. La whitelist est la solution la plus propre, éliminant à la fois le problème des navigateurs et le risque de fuite. Pour tester vos adresses notre outil de vérification de proxy est à votre disposition.