SOCKS is an Internet protocol that facilitates the routing of network packets between client-server applications via a proxy server. SOCKS performs at Layer 5 of the OSI model—the Session Layer (an intermediate layer between the presentation layer and the transport layer). Port 1080 is the well-known port designated for the SOCKS server.

SOCKS
Bill wishes to communicate with Jane over the internet, but a firewall exists on his network between them and Bill is not authorized to communicate through it himself. Therefore, he connects to the SOCKS proxy on his network and sends information about the connection he wishes to make to Jane. The SOCKS proxy opens a connection through the firewall and facilitates the communication between Bill and Jane. 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 internet browser communicates with the proxy in exactly the same way it would the target server—it sends a standard HTTP request header. The HTTP proxy reads the request and looks for the Host header. It then connects to the server specified in the header and transmits any data the server replies with back to Bill.

SOCKS 4 protocol

A typical SOCKS 4 connection request looks like this (one byte each):
Client to SOCKS Server:
field 1: SOCKS version number, 1 byte, must be 0x04 for this version
field 2: command code, 1 byte:
0x01 = establish a TCP/IP stream connection
0x02 = establish a TCP/IP port binding
field 3: network byte order port number, 2 bytes
field 4: network byte order IP address, 4 bytes
field 5: the user ID string, variable length, terminated with a null (0x00)
Server to SOCKS client:
field 1: null byte
field 2: status, 1 byte:
0x5a = request granted
0x5b = request rejected or failed
0x5c = request failed because client is not running identd (or not reachable from the server)
0x5d = request failed because client's identd could not confirm the user ID string in the request
field 3: 2 arbitrary bytes, that should be ignored
field 4: 4 arbitrary bytes, that should be ignored
This is a SOCKS 4 request to connect Fred to 66.102.7.99:80, the server replies with an "OK".
Client: 0x04 | 0x01 | 0x00 0x50 | 0x42 0x66 0x07 0x63 | 0x46 0x72 0x65 0x64 0x00
The last field is 'Fred' in ASCII, followed by a null byte.
Server: 0x00 | 0x5a | 0xXX 0xXX | 0xXX 0xXX 0xXX 0xXX
0xXX can be any byte value. The Socks 4 protocol specifies the values of these bytes should be ignored.
From this point on any data sent from the SOCKS client to the SOCKS server will be relayed to 66.102.7.99 and vice versa.
The command field can be 0x01 for "connect" or 0x02 for "bind". "bind" allows incoming connections for protocols like active FTP.
[edit]SOCKS 4a protocol
SOCKS 4a is a simple extension to SOCKS 4 protocol that allows a client that cannot resolve the destination host's domain name to specify it.
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:
field 1: SOCKS version number, 1 byte, must be 0x04 for this version
field 2: command code, 1 byte:
0x01 = establish a TCP/IP stream connection
0x02 = establish a TCP/IP port binding
field 3: network byte order port number, 2 bytes
field 4: deliberate invalid IP address, 4 bytes, first three must be 0x00 and the last one must not be 0x00
field 5: the user ID string, variable length, terminated with a null (0x00)
field 6: the domain name of the host we want to contact, variable length, terminated with a null (0x00)
Server to SOCKS client:
field 1: null byte
field 2: status, 1 byte:
0x5a = request granted
0x5b = request rejected or failed
0x5c = request failed because client is not running identd (or not reachable from the server)
0x5d = request failed because client's identd could not confirm the user ID string in the request
field 3: network byte order port number, 2 bytes
field 4: network byte order IP address, 4 bytes
A server using protocol 4A 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.
[edit]SOCKS 5 protocol

The SOCKS 5 protocol is an extension of the SOCKS 4 protocol that is defined in RFC 1928. It offers more choices of authentication, adds support for IPv6 and UDP that can be used for DNS lookups. The initial handshake now consists of the following:
Client connects and sends a greeting which includes a list of authentication methods supported.
Server chooses one (or sends a failure response if none of the offered methods are acceptable).
Several messages may now pass between the client and the server depending on the authentication method chosen.
Client sends a connection request similar to SOCKS 4.
Server responds similar to SOCKS 4.
The authentication methods supported are numbered as follows:
0x00: No authentication
0x01: GSSAPI [5]
0x02: Username/Password [6]
0x03-0x7F: methods assigned by IANA [7]
0x80-0xFE: methods reserved for private use
The initial greeting from the client is
field 1: SOCKS version number (must be 0x05 for this version)
field 2: number of authentication methods supported, 1 byte
field 3: authentication methods, variable length, 1 byte per method supported
The server's choice is communicated:
field 1: SOCKS version, 1 byte (0x05 for this version)
field 2: chosen authentication method, 1 byte, or 0xFF if no acceptable methods were offered
The subsequent authentication is method-dependent and described in RFC 1929:
The client's authentication request is
field 1: version number, 1 byte (must be 0x01)
field 2: username length, 1 byte
field 3: username
field 4: password length, 1 byte
field 5: password
Server response for authentication:
field 1: version, 1 byte
field 2: status code, 1 byte.
0x00 = success
any other value = failure, connection must be closed
The client's connection request is
field 1: SOCKS version number, 1 byte (must be 0x05 for this version)
field 2: command code, 1 byte:
0x01 = establish a TCP/IP stream connection
0x02 = establish a TCP/IP port binding
0x03 = associate a UDP port
field 3: reserved, must be 0x00
field 4: address type, 1 byte:
0x01 = IPv4 address
0x03 = Domain name
0x04 = IPv6 address
field 5: destination address of
4 bytes for IPv4 address
1 byte of name length followed by the name for Domain name
16 bytes for IPv6 address
field 6: port number in a network byte order, 2 bytes
Server response:
field 1: SOCKS protocol version, 1 byte (0x05 for this version)
field 2: status, 1 byte:
0x00 = request granted
0x01 = general failure
0x02 = connection not allowed by ruleset
0x03 = network unreachable
0x04 = host unreachable
0x05 = connection refused by destination host
0x06 = TTL expired
0x07 = command not supported / protocol error
0x08 = address type not supported
field 3: reserved, must be 0x00
field 4: address type, 1 byte:
0x01 = IPv4 address
0x03 = Domain name
0x04 = IPv6 address
field 5: destination address of
4 bytes for IPv4 address
1 byte of name length followed by the name for Domain name
16 bytes for IPv6 address
field 6: network byte order port number, 2 bytes
There are client programs that "socksify",[8] which allows adaptation of any networked software to connect to external networks via SOCKS.
[edit]Related software

Kernel SOCKS Bouncer ksb26 (Kernel Socks Bouncer) is a Linux Kernel 2.6.x Loadable Kernel Module that redirects TCP connection (to user-defined target hosts) through socks 4/5 chains.
redsocks is a Linux program that can make connection to socks proxy transparent, it also supports system-wide socksification.
SS5 Socks Server is an open-source SOCKS4/SOCKS5 server.
Dante is an open-source SOCKS4/SOCKS5 implementation with commercial support developed by Inferno Nettverk A/S.
OpenSSH allows dynamic creation of tunnels, specified via a subset of the SOCKS protocol, supporting the CONNECT command.
PuTTY is a Win32 SSH client that supports local creation of SOCKS (dynamic) tunnels through remote SSH servers.
WinSocks is a light-weight SOCKS4/SOCKS5 server developed by Proxy Labs.
SOcat (SOcket CAT) is a multipurpose relay program : includes socks4, and socks4a functionality for Linux and Mac.
FreeCap Socksifyer for Windows, any App can run its network traffic transparently via a SOCKS or HTTP proxy.
WideCap Successor of FreeCap.
Simple Socks Server for Perl: SSS is a Simple SOCKS Server written in perl that implements the SOCKS v5 protocol.
Sun Java System Web Proxy Server is a caching proxy server running on Solaris, Linux and Windows servers that supports HTtp://S, NSAPI I/O filters, dynamic reconfiguration, SOCKSv5 and reverse proxy.
BarracudaDrive Web Server, commercial SOCKS HTTP HTTPS tunnel/server, available for Windows, embedded Linux and Mac OS X.
DeleGate is a multi-purpose application level gateway and proxy server which runs on multiple platforms. Beside SOCKS it also supports HTTP(S), FTP, NNTP, SMTP, POP, IMAP, LDAP, Telnet, DNS and many more.
Freeproxy Is free proxy server software. It supports HTTP, SOCKS, and many other protocols.
WinGate is a multi-protocol proxy server and SOCKS server for Microsoft Windows.