|
---|
|
|
|
A typical SOCKS4 connection request looks like this:
VER | CMD | DSTPORT | DSTIP | ID | |
---|---|---|---|---|---|
Byte Count | 1 | 1 | 2 | 4 | Variable |
VN | REP | DSTPORT | DSTIP | |
---|---|---|---|---|
Byte Count | 1 | 1 | 2 | 4 |
Byte | Meaning |
---|---|
0x5A | Request granted |
0x5B | Request rejected or failed |
0x5C | Request failed because client is not running identd (or not reachable from server) |
0x5D | Request failed because client's identd could not confirm the user ID in the request |
For example, this is a SOCKS4 request to connect Fred to 66.102.7.99:80, the server replies with an "OK":
0x04 | 0x01 | 0x00 0x50 | 0x42 0x66 0x07 0x63 | 0x46 0x72 0x65 0x64 0x00
0x00 | 0x5A | 0xXX 0xXX | 0xXX 0xXX 0xXX 0xXX
From this point onwards, any data sent from the SOCKS client to the SOCKS server is relayed to 66.102.7.99, and vice versa.
The command field may be 0x01 for "connect" or 0x02 for "bind"; the "bind" command allows incoming connections for protocols such as active FTP.
SOCKS4a extends the SOCKS4 protocol to allow a client to specify a destination domain name rather than an IP address; this is useful when the client itself cannot resolve the destination host's domain name to an IP address. It was proposed by Ying-Da Lee, the author of SOCKS4.
The client should set the first three bytes of DSTIP to NULL and the last byte to a non-zero value. (This corresponds to IP address 0.0.0.x, with x nonzero, an inadmissible destination address and thus should never occur if the client can resolve the domain name.) Following the NULL byte terminating USERID, the client must send the destination domain name and terminate it with another NULL byte. This is used for both "connect" and "bind" requests.
Client to SOCKS server:
SOCKS4_C | DOMAIN | |
---|---|---|
Byte Count | 8+variable | variable |
Server to SOCKS client: (Same as SOCKS4)
A server using protocol SOCKS4a must check the DSTIP in the request packet. If it represents address 0.0.0.x with nonzero x, the server must read in the domain name that the client sends in the packet. The server should resolve the domain name and make connection to the destination host if it can.
The SOCKS5 protocol is defined in RFC 1928. It is an incompatible extension of the SOCKS4 protocol; it offers more choices for authentication and adds support for IPv6 and UDP, the latter of which can be used for DNS lookups. The initial handshake consists of the following:
The initial greeting from the client is:
VER | NAUTH | AUTH | |
---|---|---|---|
Byte count | 1 | 1 | variable |
VER | CAUTH | |
---|---|---|
Byte count | 1 | 1 |
The subsequent authentication is method-dependent. Username and password authentication (method 0x02) is described in RFC 1929:
VER | IDLEN | ID | PWLEN | PW | |
---|---|---|---|---|---|
Byte count | 1 | 1 | (1–255) | 1 | (1–255) |
VER | STATUS | |
---|---|---|
Byte count | 1 | 1 |
After authentication the connection can proceed. We first define an address datatype as:
TYPE | ADDR | |
---|---|---|
Byte Count | 1 | variable |
VER | CMD | RSV | DSTADDR | DSTPORT | |
---|---|---|---|---|---|
Byte Count | 1 | 1 | 1 | Variable | 2 |
VER | STATUS | RSV | BNDADDR | BNDPORT | |
---|---|---|---|---|---|
Byte Count | 1 | 1 | 1 | variable | 2 |
Since clients are allowed to use either resolved addresses or domain names, a convention from cURL exists to label the domain name variant of SOCKS5 "socks5h", and the other simply "socks5". A similar convention exists between SOCKS4a and SOCKS4.
Client software must have native SOCKS support in order to connect through SOCKS.
There are programs that allow users to circumvent such limitations:
Socksifiers allow applications to access the networks to use a proxy without needing to support any proxy protocols. The most common way is to set up a virtual network adapter and appropriate routing tables to send traffic through the adapter.
This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (January 2022) (Learn how and when to remove this message) |
Due to lack of request and packets exchange encryption it makes SOCKS practically vulnerable to man-in-the-middle attacks and IP addresses eavesdropping which in consequence clears a way to censorship by governments.