Why SOCKS5 Password Authentication Starts with Version 1
Distinguish the SOCKS5 greeting from the version field in its username/password authentication subnegotiation.
A SOCKS5 client begins with version 5, then sends version 1 during password authentication. That is not necessarily a downgrade or a wrong proxy.
The first exchange negotiates the SOCKS5 authentication method. When username/password is selected, RFC 1929 defines a separate subnegotiation whose version field is 0x01.
That authentication request includes lengths and bytes for the username and password. The server returns the subnegotiation version and a status. Only after authentication succeeds does the client send the SOCKS5 destination request.
Keep the two exchanges separate when reading a trace or implementing a client. Repeating 0x05 everywhere because the service is called SOCKS5 produces the wrong authentication message.
A successful password status also does not mean the requested destination is permitted. The following SOCKS reply can still reject that connection.
Finally, this username/password method does not encrypt its credentials. The version byte identifies a message format, not an encrypted or stronger login mode.