RFC 1929 / START HERE
SOCKS username/password, before the details
Username/Password Authentication for SOCKS V5 is one login method inside the SOCKS5 proxy protocol. An octet is an eight-bit byte.
A client and a proxy first agree to use this method. The client sends length-prefixed username and password bytes; the proxy checks them and sends a success or failure result.
The idea in one picture
Choose the method
Check credentials
Then request a relay
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
It fills the authentication step between selecting a SOCKS method and asking the proxy to relay traffic. This publication defines that small exchange, not every SOCKS command or an encrypted login protocol.
A familiar example
Imagine showing a membership card at a picnic gate before asking to use a particular table. Passing the membership check does not reserve that table. Here the password is sent in cleartext, so someone able to observe the exchange can read it; later application encryption does not protect those earlier bytes.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Select the authentication methodSOCKS5 chooses an authentication method before sending credentials. The outer protocol version and this method’s subnegotiation version are different fields.→
- Count the credential bytesThe request carries two length-prefixed byte strings. Each length counts the following field’s octets, not the whole request or the number of displayed characters.→
- Handle success and failureThe proxy checks the supplied username and password and returns a two-octet result. Authentication success allows the next protocol stage, not automatic destination access.→
- Respect lengths and stream boundariesOne-byte lengths bound each credential field, but TCP can deliver the request in several reads. Count bytes before interpreting application-specific text.→
- Keep the cleartext boundary visibleThis authentication method sends the password in cleartext. A successful login does not encrypt the exchange or give the proxy’s identity cryptographic proof.→
This introduction explains RFC 1929 (1996). Read the original RFC ↗