SOCKS5 认证方法 (RFC 1929)

SOCKS5（在RFC 1928中定义）不假设认证方法——它协商一种。只要与代理的TCP连接打开，客户端就会发送一个问候，列出它支持的认证方法，代理则选择其中一种。

客户端的问候是：一个版本字节（0x05），一个方法计数，然后是那么多的方法标识符。常见的方法有0x00 "不需要认证"，0x02 "用户名/密码"，和0xFF "没有可接受的方法"。服务器回复两个字节：版本和它选择的单一方法。如果返回0x00，你可以直接连接；如果返回0x02，客户端必须先进行用户名/密码的子协商，然后才能发出任何连接请求。如果服务器返回0xFF，则没有任何提供的方法是可接受的，它会关闭连接。这就是为什么一个经过认证的s4m SOCKS5代理在1080端口上期望你的客户端提供方法0x02。

用户名/密码方法 (0x02) 在 RFC 1929 中单独指定。这是一个微小的、自包含的交换，发生在方法协商之后和 SOCKS 请求之前：

• 客户端发送：一个子协商版本字节 (0x01 — 注意这是认证版本，而不是 SOCKS 版本)，一个字节的用户名长度，用户名，一个字节的密码长度，以及密码。
• 服务器回复两个字节：版本 (0x01) 和一个状态字节。0x00 表示成功；其他任何值表示失败，服务器关闭连接。

只有在成功状态之后，客户端才会继续进行实际的 SOCKS5 CONNECT 请求，指定目标。由于用户名和密码都是长度前缀的单字节，每个都限制为 255 字节。请参阅我们的 代理认证指南，了解这在真实客户端和 API 中如何处理凭证。

关键的诚实点：RFC 1929以明文传输用户名和密码。这些字节没有加密或哈希处理——任何能够观察您与代理之间TCP连接的人都可以读取您的凭据。RFC本身承认这一点，并警告这种方法仅在这种暴露是可接受的情况下才合适。

这在实践中意味着：SOCKS5用户名/密码认证的安全性依赖于通往代理的路径是可信的，或者将整个SOCKS连接包装在某种加密中。人们使用的缓解措施包括通过TLS或SSH隧道SOCKS5，在可信网络上运行代理，或依赖IP白名单而不是（或除了）凭据——这使得专用IP变得可行。原则上存在其他SOCKS5认证方法（例如RFC 1928中的GSS-API），但用户名/密码仍然是最广泛实现的方法，因此理解其明文特性——并且不将重要密码重复用作代理凭据——是很重要的。