Por qué la autenticación por contraseña de SOCKS5 empieza con la versión 1
Distinga el saludo de SOCKS5 del campo de versión en su subnegociación de usuario/contraseña.
Un cliente SOCKS5 comienza con la versión 5 y luego envía la versión 1 durante la autenticación por contraseña. Eso no es necesariamente una degradación ni un proxy incorrecto.
El primer intercambio negocia el método de autenticación de SOCKS5. Cuando se elige usuario/contraseña, el RFC 1929 define una subnegociación aparte cuyo campo de versión es 0x01.
Esa solicitud de autenticación incluye longitudes y bytes para el usuario y la contraseña. El servidor devuelve la versión de la subnegociación y un estado. Solo después de que la autenticación se realiza con éxito el cliente envía la solicitud de destino SOCKS5.
Mantenga los dos intercambios separados al leer una traza o implementar un cliente. Repetir 0x05 en todas partes porque el servicio se llama SOCKS5 produce el mensaje de autenticación incorrecto.
Un estado de contraseña correcto tampoco significa que el destino solicitado esté permitido. La siguiente respuesta SOCKS aún puede rechazar esa conexión.
Por último, este método de usuario/contraseña no cifra sus credenciales. El byte de versión identifica un formato de mensaje, no un modo de inicio de sesión cifrado ni más fuerte.