SOCKS
From Wikipedia, the free encyclopedia
- This article is about an internet protocol. For other uses, see Sock (disambiguation).
SOCKS is an Internet protocol that allows client-server applications to transparently use the services of a network firewall. SOCKS is an abbreviation for "SOCKetS" [1].
Clients behind a firewall wanting to access exterior servers connect to a SOCKS proxy server instead. This proxy server controls the eligibility of the client to access the external server and passes the request on to the server. SOCKS can also be used in the opposite way, letting clients outside the firewall ("exterior clients") connect to servers inside the firewall (internal servers).
The protocol was originally developed by David Koblas, a system administrator for 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 and SOCKS became publicly available.[1] The protocol was extended to version 4 by Ying-Da Lee of NEC.
Unofficial SOCKS 4a extensions add support for DNS names to resolve names with SOCKS server. The current version 5 of the protocol, RFC 1928 or authenticated firewall traversal, extends the previous version by supporting UDP, authentication, letting the SOCKS server resolve hostnames for the SOCKS client, and IPv6.
The SOCKS reference architecture and client are owned by Permeo Technologies,[2] a spin-off from NEC.[3]
According to the OSI model it is an intermediate layer between the application layer and the transport layer.
Contents |
[edit] SOCKS 4 protocol
A typical SOCKS 4 connection request looks like this (each number is one byte):
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: network byte order port number, 2 bytes field 4: network byte order ip address, 4 bytes
Example:
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 Server: 0x00 | 0x5a | 0x00 0x50 | 0x42 0x66 0x07 0x63
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
An extension of the SOCKS 4 protocol that offers more choices of authentication. 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 SOCKS4. Server responds similar to SOCKS4.
The authentication methods supported are numbered as follows:-
0x00 - No authentication 0x01 - GSSAPI 0x02 - Username/Password 0x03..0x7F - methods assigned by IANA 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 when no acceptable methods were offered.
The subsequent authentication is method-dependent.
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 = IP V4 address (address field is 4 bytes long) 0x03 = Domain name (address field is variable) 0x04 = IP V6 address (address field is 16 bytes long) field 5: destination address, 4/16 bytes or 1+domain name length. If address type is 0x03 then the address consists of a length byte followed by the domain name. field 6: network byte order port number, 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, 0x00 field 4: address type, 1 byte:- 0x01 = IP V4 address (address field is 4 bytes long) 0x03 = Domain name (address field is variable) 0x04 = IP V6 address (address field is 16 bytes long) field 5: destination address, 4/16 bytes or 1+domain name length. If address type is 0x03 then the address consists of a length byte followed by the domain name. field 6: network byte order port number, 2 bytes
[edit] SOCKS servers
List of SOCKS servers programs:
- Dante Socks Server
- FreeProxy Includes a SOCKS server. Runs on Windows 98, NT, 2000, XP and Server 2003
- AnalogX Proxy Includes a SOCKS server. Runs on Windows 95, 98, NT, 2000, XP
- Java Socks Server
- Socks4 Server
- SS5 Socks Server
- nylon
- 3proxy
- WinGate
- SSH (OpenSSH on Unix/Linux, PuTTY on Windows) (use dynamic port forwarding)
- DeleGate
- Antinat
[edit] SOCKS clients
There are client programs that socksify [4], which allows adaptation of any software to connect to external networks via SOCKS.
List of SOCKS clients:
- Dante client
- FreeCap
- Proxifier
- Hummingbird socks
- ProxyCap
- SocksCap
- tsocks
- socat
- connect
- TunnelIt SOCKS over SSH
- NetConceal Anonymizer
- GNet Library
| Client | License | Version | Release date | Platform | Support |
|---|---|---|---|---|---|
| Dante client | BSD/Carnegie Mellon University | 1.1.19 | 01/2006 | POSIX | v4, v5, HTTP |
| FreeCap | GPL | 3.18 | 02/2006 | Windows | v4, v5, HTTPS |
| Proxifier | Shareware | 2.0 | 02/2006 | Windows | v4, v5, HTTPS |
| ProxyCap | Single or multiuser fee | 3.0 | - | Windows | - |
| SocksCap | Non-Commercial home use | 2.38 | 06/2005 | Windows | v4, v5 |
| tsocks | GPL | 1.8 | 10/2002 | POSIX (source) | v4, v5 |
| nylon | 3-clause BSD | - | 06/2003 | OpenBSD | v4, v5 |
| socat | GPL | - | 09/2005 | POSIX | - |
| NetConceal Anonymizer | Shareware | 3.6.41 | 05/2005 | Windows | v4, v5, HTTPS |
[edit] References
- ^ Darmohray, Tina. "Firewalls and fairy tales". ;LOGIN:. Vol 30, no. 1.
[edit] External links
- RFC 3089 - A SOCKS-based IPv6/IPv4 Gateway Mechanism
- RFC 1961 - GSS-API Authentication Method for SOCKS Version 5
- RFC 1929 - Username/Password Authentication for SOCKS V5
- SOCKS4.Protocol - SOCKS Protocol Version 4
- SOCKS4A.Protocol - SOCKS Protocol Version 4A
- RFC 1928 - SOCKS Protocol Version 5
