Keep the cleartext boundary visible
05This authentication method sends the password in cleartext. A successful login does not encrypt the exchange or give the proxy’s identity cryptographic proof.
Separate later-layer comparison: application TLS begins after authentication and relay setup. Its later interval does not cover the earlier cleartext credential exchange.
Source for this drawing: RFC 1929 · Read RFC section 3 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Recognize what authentication establishes and what this method leaves exposed.
- RFC 1929 §3 states that the request carries the password in cleartext. It is not recommended where sniffing is possible and practical. That wording is not an invented uppercase MUST NOT, and method selection does not remove the exposure.
- The fictional blanket! password is readable in the client-to-proxy request. A passive observer who can see those bytes can read the password. This scene illustrates the stated risk; it performs no interception and uses no real credential.
- The server’s username/password check authenticates the supplied client credentials to that server. This exchange defines no encrypted password envelope, server certificate, message-integrity check, freshness challenge or replay protection.
- After authentication, a proxy can still deny the requested destination under the separate SOCKS request procedure (RFC 1928 §§3–4,6). STATUS 00 is not destination authorization or proof of an end-to-end connection.
- If an application later negotiates TLS with a destination through an established relay, that later protection does not retroactively encrypt a password already sent to the proxy. This comparison is a boundary example, not a TLS requirement or deployment recipe added to RFC 1929.
Four separate security views; the last is a later-layer comparison, not a claim that RFC 1929 supplies TLS or protects the earlier authentication bytes.
Read the RFC section ↗