SOCKS5 Authentication Methods (RFC 1929)

SOCKS5 (defined in RFC 1928) does not assume an authentication method — it negotiates one. As soon as the TCP connection to the proxy opens, the client sends a greeting listing the authentication methods it supports, and the proxy picks one.

The client's greeting is: a version byte (0x05), a count of methods, then that many method identifiers. The common methods are 0x00 "no authentication required", 0x02 "username/password", and 0xFF "no acceptable methods". The server replies with two bytes: the version and the single method it chose. If it returns 0x00, you connect straight away; if it returns 0x02, the client must now run the username/password sub-negotiation before it can issue any connect request. If the server returns 0xFF, none of the offered methods was acceptable and it closes the connection. This is why an authenticated s4m SOCKS5 proxy on port 1080 expects your client to offer method 0x02.

The username/password method (0x02) is specified separately in RFC 1929. It is a tiny, self-contained exchange that happens after method negotiation and before the SOCKS request:

• The client sends: a sub-negotiation version byte (0x01 — note this is the auth version, not the SOCKS version), a one-byte username length, the username, a one-byte password length, and the password.
• The server replies with two bytes: the version (0x01) and a status byte. 0x00 means success; anything else means failure, and the server closes the connection.

Only after a success status does the client proceed to the actual SOCKS5 CONNECT request naming the destination. Because both username and password are length-prefixed single bytes, each is limited to 255 bytes. See our proxy authentication guide for how this plays out with real clients and the API for credential handling.

RFC 1929 sends the username and password in plaintext between the client and proxy. HTTPS to the destination does not encrypt this authentication exchange.

Use a trusted network path or an encrypted transport explicitly supported by the provider. A dedicated IP does not encrypt credentials or replace them on current s4m endpoints. Related topic: dedicated IP.