Socks5 protocol is a network transport protocol primarily used for intermediary communication between clients and external servers. The Socks5 server forwards requests received from the client to the actual target server, simulating a frontend behavior. Here, communication between the client and Socks5 also occurs via the TCP/IP protocol. The client sends the requests intended for the real server to the SOCKS5 server, which then forwards them to the actual server. In the following, we will analyze socks5 proxy protocol to learn the principle of the sockets5 protocol with Unicorn network analyzer.
Socks5 Protocol Communication Flow
- Client-server authentication
- The proxy server responds to client requests
- The client sends the request address to the proxy server
- The proxy server responds to the client request (the proxy establishes a link with the remote server, and the proxy server responds to the client request)
- The client transmits data to the proxy
- The proxy server forwards the data to a remote server
- The remote server sends the data to the proxy server
- The proxy server forwards the data to the client
1. Client-server Authentication
The client connects to the server, and sends a version identifier/method selection message:
+----+----------+----------+
|VER | NMETHODS | METHODS |
+----+----------+----------+
| 1 | 1 | 1 to 255 |
+----+----------+----------+The VER field is set to X’05’ for this version of the Socks5 protocol. The NMETHODS field contains the number of method identifier octets that appear in the METHODS field. See below for packet decoding:
The server selects from one of the methods given in METHODS, and sends a METHOD selection message:
+----+--------+
|VER | METHOD |
+----+--------+
| 1 | 2 |
+----+--------+See below for packet decoding:
If the selected METHOD is X’FF’, none of the methods listed by the client are acceptable, and the client MUST close the connection. The values currently defined for METHOD are:
o X'00' NO AUTHENTICATION REQUIRED
o X'01' GSSAPI
o X'02' USERNAME/PASSWORD
o X'03' to X'7F' IANA ASSIGNED
o X'80' to X'FE' RESERVED FOR PRIVATE METHODS
o X'FF' NO ACCEPTABLE METHODSThe client and server then enter a method-specific sub-negotiation.
If the Socks5 proxy server sends 5 2, it means that version 5 has selected the handshake method of “username and password authentication”. At this time, the client will send the account and password data to the proxy server, which will verify it and return the result. The format is as follows:
+----+------+----------+------+----------+
|VER | ULEN | UNAME | PLEN | PASSWD |
+----+------+----------+------+----------+
| 1 | 1 | 1 to 255 | 1 | 1 to 255 |
+----+------+----------+------+----------+
The VER field contains the current version of the subnegotiation, which is X'01'. The ULEN field contains the length of the UNAME field that follows. The UNAME field contains the username as known to the source operating system. The PLEN field contains the length of the PASSWD field that follows. The PASSWD field contains the password association with the given UNAME.
See below for packet decoding:
The server verifies the supplied UNAME and PASSWD, and sends the following response:
+----+--------+
|VER | STATUS |
+----+--------+
| 1 | 1 |
+----+--------+
A STATUS field of X'00' indicates success. If the server returns a `failure' (STATUS value other than X'00') status, it MUST close the connection. See below for packet decoding:
2. The Client Sends the Request Address to the Socks5 Proxy Server
Once the method-dependent subnegotiation has completed, the client sends the request details. If the negotiated method includes encapsulation for purposes of integrity checking and/or confidentiality, these requests MUST be encapsulated in the method-dependent encapsulation.
The Socks5 protocol request is formed as follows:
+----+-----+-------+------+----------+----------+
|VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+
Where:
o VER protocol version: X'05'
o CMD
o CONNECT X'01'
o BIND X'02'
o UDP ASSOCIATE X'03'
o RSV RESERVED
o ATYP address type of following address
o IP V4 address: X'01'
o DOMAINNAME: X'03'
o IP V6 address: X'04'
o DST.ADDR desired destination address
o DST.PORT desired destination port in network octet
order
The SOCKS server will typically evaluate the request based on source and destination addresses, and return one or more reply messages, as appropriate for the request type.
See below for packet decoding:
The SOCKS request information is sent by the client as soon as it has established a connection to the SOCKS server, and completed the authentication negotiations. The server evaluates the request, and returns a reply formed as follows:
+----+-----+-------+------+----------+----------+
|VER | REP | RSV | ATYP | BND.ADDR | BND.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+
Where:
o VER protocol version: X'05'
o REP Reply field:
o X'00' succeeded
o X'01' general SOCKS server failure
o X'02' connection not allowed by ruleset
o X'03' Network unreachable
o X'04' Host unreachable
o X'05' Connection refused
o X'06' TTL expired
o X'07' Command not supported
o X'08' Address type not supported
o X'09' to X'FF' unassigned
o RSV RESERVED
o ATYP address type of following address
See below for packet decoding:
Start Transferring Traffic
At this point, you have succeeded, and then it’s time to transfer traffic and transfer traffic.
Summary
Socks5 protocol is a very general proxy protocol, so no matter what encrypted transmission we want to achieve, we need to set up a Socks5 server on the client side to understand the request of the client such as the browser and convert it into a private protocol. In this article, we have taken a preliminary look at the structure of Socks5 and understood the transmission process of the Socks5 protocol.