Métodos de autenticación SOCKS5 (RFC 1929)

SOCKS5 (definido en RFC 1928) no asume un método de autenticación — negocia uno. Tan pronto como se abre la conexión TCP al proxy, el cliente envía un saludo que enumera los métodos de autenticación que soporta, y el proxy elige uno.

El saludo del cliente es: un byte de versión (0x05), un conteo de métodos, y luego tantos identificadores de método. Los métodos comunes son 0x00 "sin autenticación requerida", 0x02 "nombre de usuario/contraseña", y 0xFF "sin métodos aceptables". El servidor responde con dos bytes: la versión y el único método que eligió. Si devuelve 0x00, te conectas de inmediato; si devuelve 0x02, el cliente debe ahora ejecutar la sub-negociación de nombre de usuario/contraseña antes de poder emitir cualquier solicitud de conexión. Si el servidor devuelve 0xFF, ninguno de los métodos ofrecidos fue aceptable y cierra la conexión. Esta es la razón por la que un proxy SOCKS5 s4m autenticado en el puerto 1080 espera que tu cliente ofrezca el método 0x02.

El método de nombre de usuario/contraseña (0x02) se especifica por separado en RFC 1929. Es un intercambio pequeño y autónomo que ocurre después de la negociación del método y antes de la solicitud SOCKS:

• El cliente envía: un byte de versión de sub-negociación (0x01 — nota que esta es la versión de autenticación, no la versión SOCKS), un byte de longitud del nombre de usuario, el nombre de usuario, un byte de longitud de la contraseña y la contraseña.
• El servidor responde con dos bytes: la versión (0x01) y un byte de estado. 0x00 significa éxito; cualquier otra cosa significa fallo, y el servidor cierra la conexión.

Solo después de un estado de éxito el cliente procede a la solicitud CONNECT SOCKS5 real nombrando el destino. Dado que tanto el nombre de usuario como la contraseña están precedidos por su longitud en un solo byte, cada uno está limitado a 255 bytes. Consulta nuestra guía de autenticación de proxy para ver cómo se desarrolla esto con clientes reales y la API para el manejo de credenciales.

El punto crítico y honesto: el RFC 1929 transmite el nombre de usuario y la contraseña en texto plano. Los bytes no están encriptados ni hashados; cualquiera que pueda observar la conexión TCP entre tú y el proxy puede leer tus credenciales. El propio RFC reconoce esto y advierte que el método solo es apropiado donde esa exposición sea aceptable.

Lo que esto significa en la práctica: la seguridad de la autenticación de nombre de usuario/contraseña de SOCKS5 depende de que la ruta al proxy sea confiable, o de envolver toda la conexión SOCKS en algo encriptado. Las mitigaciones que la gente utiliza incluyen tunelizar SOCKS5 sobre TLS o SSH, ejecutar el proxy sobre una red confiable, o confiar en la lista blanca de IP en lugar de (o además de) credenciales, lo que un IP dedicado hace práctico. Existen otros métodos de autenticación SOCKS5 en principio (por ejemplo, GSS-API del RFC 1928), pero el nombre de usuario/contraseña sigue siendo, con mucho, el más ampliamente implementado, por lo que entender su naturaleza en texto plano — y no reutilizar una contraseña importante como credencial de proxy — es importante.