SOCKS


SOCKS is an Internet protocol that exchanges network packets between a client and server through a proxy server. SOCKS5 optionally provides authentication so only authorized users may access a server. Practically, a SOCKS server proxies TCP connections to an arbitrary IP address, and provides a means for UDP packets to be forwarded.
SOCKS performs at Layer 5 of the OSI model. A SOCKS server accepts incoming client connection on TCP port 1080.

History

The protocol was originally developed/designed by David Koblas, a system administrator of MIPS Computer Systems. After MIPS was taken over by Silicon Graphics in 1992, Koblas presented a paper on SOCKS at that year's Usenix Security Symposium, making SOCKS publicly available. The protocol was extended to version 4 by Ying-Da Lee of NEC.
The SOCKS reference architecture and client are owned by Permeo Technologies, a spin-off from NEC.
The SOCKS5 protocol was originally a security protocol that made firewalls and other security products easier to administer. It was approved by the IETF in 1996 as RFC 1928. The protocol was developed in collaboration with Aventail Corporation, which markets the technology outside of Asia.

Usage

SOCKS is a de facto standard for circuit-level gateways.
The circuit/session level nature of SOCKS make it a versatile tool in forwarding any TCP traffic, creating a good interface for all types of routing tools. It can be used as:
SOCKS operates at a lower level than HTTP proxying: SOCKS uses a handshake protocol to inform the proxy software about the connection that the client is trying to make, and then acts as transparently as possible, whereas a regular proxy may interpret and rewrite headers. Though HTTP proxying has a different usage model in mind, the CONNECT method allows for forwarding TCP connections; however, SOCKS proxies can also forward UDP traffic and work in reverse, while HTTP proxies cannot. HTTP proxies are traditionally more aware of the HTTP protocol, performing higher-level filtering.

SOCKS

Bill, or any client for that matter, wishes to communicate with Chris over the internet, but a firewall between them exists on his network, where Bill is not authorized to communicate with Chris directly. So, Bill connects to the SOCKS proxy on his network, informing it about the connection he wishes to make to Chris; the SOCKS proxy opens a connection through the firewall and facilitates the communication between Bill and Chris.
For more information on the technical specifics of the SOCKS protocol, see the sections below.

HTTP

Bill wishes to download a web page from Jane, who runs a web server. Bill cannot directly connect to Jane's server, as a firewall has been put in place on his network. In order to communicate with the server, Bill connects to his network's HTTP proxy. His web browser communicates with the proxy in exactly the same way that it would directly with Jane's server if that were possible; that is, it sends a standard HTTP request header. The HTTP proxy connects to Jane's server, and then transmits back to Bill any data that Jane's server returns.

Protocol

SOCKS4

A typical SOCKS4 connection request looks like this:
VERCMDDSTPORTDSTIPID
Byte Count1124Variable

;VER: SOCKS version number, 0x04 for this version
;CMD: command code:
;DSTPORT:2-byte port number
;DESTIP: IPv4 Address, 4 bytes
;ID: the user ID string, variable length, null-terminated.
VNREPDSTPORTDSTIP
Byte Count1124

;VN: reply version, null byte
;REP: reply code
;DSTPORT: destination port, meaningful if granted in BIND, otherwise ignore
;DSTIP: destination IP, as above - the ip:port the client should bind to
For example, this a SOCKS4 request to connect Fred to 66.102.7.99:80, the server replies with an "OK":
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

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. 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_CDOMAIN
Byte Count8+variablevariable

;SOCKS4_C: SOCKS4 client handshake packet
;DOMAIN: the domain name of the host to contact, variable length, null terminated
Server to SOCKS client:
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.

SOCKS5

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:
VERNAUTHAUTH
Byte count11variable

; VER: SOCKS version
; NAUTH: Number of authentication methods supported, uint8
; AUTH: Authentication methods, 1 byte per method supported
; VER: SOCKS version
; CAUTH: chosen authentication method, or 0xFF if no acceptable methods were offered
The subsequent authentication is method-dependent. Username and password authentication is described in RFC 1929:
VERIDLENIDPWLENPW
Byte count111

; VER: 0x01 for current version of username/password authentication
; IDLEN, ID: Username length, uint8; username as bytestring
; PWLEN, PW: Password length, uint8; password as bytestring
; VER: 0x01 for current version of username/password authentication
; STATUS: 0x00 success, otherwise failure, connection must be closed
After authentication the connection can proceed. We first define an address datatype as:
; TYPE: type of the address. One of:
; ADDR: the address data that follows. Depending on type:
VERCMDRSVDSTADDRDSTPORT
Byte Count111Variable2

; VER: SOCKS version
; CMD: command code:
; RSV: reserved, must be 0x00
; DSTADDR: destination address, see the address structure above.
; DSTPORT: port number in a network byte order
VERSTATUSRSVBNDADDRBNDPORT
Byte Count111variable2

; VER: SOCKS version
; STATUS: status code:
; RSV: reserved, must be 0x00
; BNDADDR: server bound address, in the "SOCKS5 address" format specified above
; BNDPORT: server bound port number in a network byte order
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.

Software

Servers

SOCKS proxy server implementations

Client software must have native SOCKS support in order to connect through SOCKS. There are programs that allow users to circumvent such limitations:

Socksifiers

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.