The SOCKS protocol is an Internet protocol that allows client - server applications allowed, protocol-independent, and transparent to use the services of a proxy server. SOCKS is an abbreviation for "Sockets ".
Clients behind a firewall that want to connect to an external server, connect instead to a SOCKS proxy. This proxy server checks the external server authorization of the client to contact, and forwards the request to the server.
The SOCKS protocol was originally developed by NEC ( SOCKS 4). The current version 5 of the protocol as described in RFC 1928 extends the previous versions support for UDP, authentication, name resolution, the SOCKS server and IPv6.
In the TCP / IP model, there is an intermediate layer between the application layer and the transport layer.
The SOCKS 4 protocol
A typical SOCKS 4 connection request looks like this ( each number is a byte ):
Client: 4 1 0 80 66 102 7 99 0
(4 is the SOCKS version, 1 is the connection request, 0 80 is the port 66 102 7 99 the IP address to which the client wants to connect, 0 if no user name is used )
Server: 0 90 0 80 66 102 7 99
(0 90 means that the request has been accepted, 0 80 is the port 66102 7 99, the IP address to which the connection has been established )
Then all the data sent by the client to the SOCKS proxy, forwarded to 18.104.22.168. Conversely, all data is sent from 22.214.171.124 to the SOCKS proxy, which forwards it to the client.
The SOCKS 5 protocol
Unlike SOCKS 4 is sent before the actual connection request a " version identifier / method selection message". This message contains various authentication methods that takes the client and the server from which one chooses to use. This looks like this ( the numbers indicate the number of bytes ):
VER is set to the version that is 0x05. NMETHODS indicates the number of the proposed authentication methods. METHODS Finally, then, the proposed authentication methods. There are the following options:
The server then accepts one of the proposed methods of authentication:
VER is the version, so again 0x05. METHOD is the accepted and therefore used method. 0xFF means no method is acceptable and the client must disconnect.
The connection request
She looks at SOCKS5 like this:
VER is again the version 0x05. CMD is the command to the server to execute:
- 0x01: Establishing a TCP connection
- 0x02: accept a TCP connection, that is, open a server.
- 0x03: Set up a UDP forwarding
RSV is reserved and must be 0x00. ATYP is the type of destination address:
- 0x01 for an IPv4 address
- 0x03 for a domain name
- 0x04 for an IPv6 address
DST.ADDR is the destination address.
- 4 bytes at 0x01 ATYP
- 1 byte length of the domain, in bytes (first byte represents the length of the domain is ) at ATYP 0x03
- 16 bytes at 0x04 ATYP
DST.PORT is the destination port.
- Translation of the port number in radix 256
- First byte = Port number / 256 ( round down to whole number ( high byte ) )
- Second byte = port number modulo 256 ( low byte )
The response from the server looks the same. The only difference is that in CMD REP ( reply), that is to say, renamed. The following values are allowed for REP:
List of SOCKS servers:
- Delegate universal proxy server, including socks server, open source
- Dante socks server
- Java socks server, open source
- Socks4 server
- SS5 Socks Server
- SSH as socks server
There are programs that allow other programs to reach external networks via SOCKS, without having to bring special support for:
List of SOCKS clients:
- Dante client
- Hummingbird socks
- SocksCap ( Google Link )
- RFC 3089 - A SOCKS -based IPv4/IPv6-Gateway-Mechanismus
- RFC 1961 - GSS -API authentication method for SOCKS V5
- RFC 1929 - Username / Password Authentication for SOCKS V5
- RFC 1928 - SOCKS Protocol Version 5
- IT architecture
- Internet application protocol