A while ago we looked at using Tor and Privoxy to allow us to remain anonmyous while browsing the web. I briefly mentioned SOCKS while we were configuring our web browser to route traffic through the onion network. This prompted me to take a deeper look at SOCKS.

SOCKS is a network proxy protocol that routes packets between a client and server using a proxy server. SOCKS service is usually provided on port 1080. The advantage to this is that hosts who wish to connect a remote system don’t have to do so directly. They are able to direct their TCP or UDP traffic to the SOCKS proxy server and the proxy server will then relay these packets to their intended destination. The intended destination has no idea the true origin of the data as it believes the SOCKS server is the client. The SOCKS server is able to do this after authenticating and authorizing requests, establishing a proxy connection, and then forwarding the data between the respective hosts.

There are two major versions of SOCKS, version 4 and version 5. SOCKS version 4 does not have an official RFC, however, SOCKS version 5 does.

SOCKS version 4 comes in two flavors: SOCKS version 4 and SOCKS version 4a. SOCKS version 4a is an extension to SOCKS version 4 that allows a client that cannot resolve the destination host’s domain name to specify it. Both variations are unable to provide authentication or UDP support.

SOCKS version 5 adds authentication and UDP support while extending the addressing scheme to encompass DNS resolution and IPv6 addresses.

Details about how SOCKS works can be found in RFC 1928 and at the Wikipedia article SOCKS.