Pourquoi l'authentification par mot de passe SOCKS5 commence par la version 1
Distinguez le salut SOCKS5 du champ de version de sa sous-négociation nom d'utilisateur/mot de passe.
Un client SOCKS5 commence par la version 5, puis envoie la version 1 lors de l'authentification par mot de passe. Ce n'est pas nécessairement une rétrogradation ni un proxy erroné.
Le premier échange négocie la méthode d'authentification SOCKS5. Lorsque nom d'utilisateur/mot de passe est choisi, la RFC 1929 définit une sous-négociation distincte dont le champ de version est 0x01.
Cette demande d'authentification comprend des longueurs et des octets pour le nom d'utilisateur et le mot de passe. Le serveur renvoie la version de la sous-négociation et un statut. Ce n'est qu'après la réussite de l'authentification que le client envoie la demande de destination SOCKS5.
Gardez les deux échanges séparés lorsque vous lisez une trace ou implémentez un client. Répéter 0x05 partout parce que le service s'appelle SOCKS5 produit le mauvais message d'authentification.
Un statut de mot de passe réussi ne signifie pas non plus que la destination demandée est autorisée. La réponse SOCKS suivante peut encore refuser cette connexion.
Enfin, cette méthode nom d'utilisateur/mot de passe ne chiffre pas ses identifiants. L'octet de version identifie un format de message, pas un mode de connexion chiffré ou plus fort.