Internet Anonymity Protocols: SOCKS

Internet Anonymity Protocols

SOCKS

SOCKS is a protocol generalizing web proxies to ANY TCP connection. It serves as an intermediate protocol, which is implemented between the originating IP and the SOCKS proxy server, commanding it to establish connections to other hosts.

The SOCKS protocol basically relays TCP connections to allow users transparent access through the server. SOCKS was initially designed for firewalls, in which organizations wanted all outbound communication to go through one server. Because the protocol is independent of the application protocol, it can be used for many different services. Relay setup is done at the beginning of the user – proxy connection. After the connection is set up, no more headers are sent, so the overhead is minimal.

SOCKS 4 (RFC)

The socks protocol is a protocol between the user (the entity needing anonymity) and the proxy, to control to which destination server he wishes to connect.

This protocol has two basic operations: CONNECT and BIND.

CONNECT

The client connects to the SOCKS server and sends this request for the proxy to connect to the destination server instead of the client. The client includes in this request packet the IP address and port of the destination server. The Connect request packet is as follows:

+---+---+---+---+---+---+---+---+---+---+....+-—-+

+---+---+---+---+---+---+---+---+---+---+....+-—-+

# of bytes:1 1 2 4 variable 1

VN: SOCKS version number. Should be 4.

CD: Command Code: should be 1 for CONNECT.

USERID: optional field for identifying the client when identification is used.

NULL: should be zero.

After the SOCKS server receives the packet, it tries to establish a regular connection to the destination IP and port. A reply packet is sent to the client with a command code as follows:

90: Request granted

91: Request requested or failed.

92: Request rejected because the SOCKS server can't identify the userid.

93: Request rejected because the userid is invalid.

The reply packet is as follows:

+----+----+----+----+----+----+----+----+

| VN | CD | DSTPORT | DSTIP |

+----+----+----+----+----+----+----+----+

# of bytes:1 1 2 4

VN: Reply code version. Should be 0.

CD: One of the above reply codes.

BIND

There are some application protocols (such as FTP) in which there is a need for the client to open a dynamic listen port for a returning inbound connection back from the server. Since it is actually the SOCKS server which establishes the connection, it should be specifically requested by the client to start listening on a dedicated port. The destination server only knows the SOCKS server IP, so it will try to connect back to the SOCKS server. Therefore the SOCKS server should listen on a port. This is what the BIND operation provides.

The request packet is identical to the CONNECT request packet, but the CD should be set to 2 to indicate a BIND request. BIND is always used after connect, so in this case, the destination port and IP fields of the request packets should be identical to the original fields in the CONNECT request.

The server replies to the client with a packet identical to the reply packet of the CONNECT request. In this case the dstport field has a special meaning, which is the port number on which the socks server will listen to inbound connection that will be relayed back to the client. The socks server maintains the connection with the client, until the application server tries to connect back. In such a case, the socks server sends a second reply packet. From now on, it continues by relaying all data arriving from the application server, back to the client.

After the connection is set up, and the SOCKS reply and request packets between the user and the proxy have been exchanged, the SOCKS proxy simply relays the two connections. Every TCP packet received from the user is sent, as is, to the destination server, and vice versa. No other packets or any modifications are done to the information in those pipes.

The SOCKS 5 (RFC) protocol expands the previous version (it is backward compatible) and adds two main new functions:

1. Authentication: various methods for the server to authenticate the client

2. UDP proxy: A method for forwarding UDP packets through the SOCKS server.

SOCKS servers (specifically free public access ones) are less common than web proxies but are much more flexible. They basically offer the same means of anonymity provided by regular web proxies (and described in the proxy section). All anonymizer methods have the same kind anonymity achieved against the destination server, the proxy server or eavesdroppers.

Another drawback of SOCKS method is that it is not well integrated into today's main operating system and user applications. Mostly, there is a need to download some third party application in order to use SOCKS. This is a real disadvantage comparing to web proxies, since all browsers have built in support for regular proxies.