SOCKS is an Internet protocol that exchanges network packets between any client and a server through a designated proxy. In addition, the SOCKS5 protocol provides progressive authentication authorization. This means that only authorized people can access the designated servers. In practice, a SOCKS server routes incoming TCP connections to a random IP address and enables the means by which UDP packets are forwarded.
SOCKS performs all of its operations at Layer 5 of the OSI model. This layer is an intermediate layer between the session, presentation, and transport layers. The SOCKS server accepts incoming connections on TCP port 1080 and allows clients to connect through the designated proxy server.
Theory of how the SOCKS protocol works
SOCKS is a virtual protocol standard for gateways.
SOCKS is used to create an alternate path for otherwise blocked network traffic. In cases where traffic is blocked by governments, system administrators, etc., the SOCKS protocol is used to bypass those blocks.
Some SSH packages (such as OpenSSH) support dynamic port forwarding, which allows the standard user to create a SOCKS proxy on the local network. This option can allow the user to connect only to blocked servers.
The Tor proxy software, on the other hand, provides users with a graphical SOCKS interface.
The SOCKS protocol also acts as a barrier against cyber attacks.
HTTP Proxy vs SOCKS: Clash of Proxies
Basically, the SOCKS protocol is more passive than HTTP proxies. The SOCKS proxy software uses a controller for the connection made by the client. This controller can analyze the packets received and sent and allow the software to act as a barrier (a standard HTTP proxy is used for basic protocols such as FTP).
Unlike HTTP, the SOCKS protocol can monitor TCP connections and control UDP traffic using various proxy controls.
However, HTTP proxies traditionally use control methods that provide a higher level of filtering (a different control can be used for each connection method).
Protocol Types
HTTP proxies are primarily designed to handle HTTP traffic. They operate at the application layer of the OSI model and are optimized for web browsing.
SOCKS proxies, on the other hand, support a wider range of applications and protocols, including HTTP, FTP, SMTP, and more. They operate at the transport layer and are more versatile in handling different types of traffic.
Encryption
By default, HTTP proxies do not encrypt communications between the client and the proxy. However, HTTPS connections between the proxy and the destination server can be encrypted.
SOCKS proxies can be used for both encrypted and unencrypted communication. They can easily handle protocols such as HTTPS.
Authentication
HTTP proxies generally support basic authentication and can integrate with other authentication mechanisms.
SOCKS proxies support multiple authentication methods, including username/password, Generic Security Services API (GSS-API), and more. This provides a higher level of security.
Firewall Traversal
HTTP proxies often work well with firewalls because they use standard ports (for example, 80 for HTTP and 443 for HTTPS).
SOCKS proxies can pass through firewalls more easily because they can handle different types of traffic and can be configured to use non-standard ports.
Performance
HTTP proxies tend to be faster for web-related activities because they are optimized to handle HTTP traffic.
SOCKS proxies can provide better performance for non-web applications and scenarios involving a wider range of protocols such as P2P file sharing.
SOCKS Versions
SOCKS4
We can summarize a default SOCKS4 connection request as follows:
SOCKS client to the main SOCKS server:
field 1: SOCKS version must be 0x04 for 1 byte.
field 2: Command code for 1 byte:
0x01 = TCP/IP stream connection
0x02 = TCP/IP port binding
field 3 : Port number, 2 bytes (in byte order on the network)
field 4 : IP address, 4 bytes (in byte order on the network)
field 5 : User ID string (0x00)
SOCKS server to SOCKS main 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 responds 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, all data sent from the SOCKS client to the SOCKS server is treated as a connection.
The command field can switch to 0x02 or 0x01 standards for active FTP connections.
SOCKS4a
This protocol extends the SOCKS4 protocol to identify a target domain instead of finding a network. This is useful when the domain name cannot be resolved by an IP address.
The first step for the client is to set the initial three bytes of DSTIP to NULL, and the fourth byte to a non-zero value. As such, the corresponding IP address would be 0.0.0.x, with x being a nonzero value. This IP address is an inadmissible destination and should never occur if the client can resolve the domain name. After the USERID is terminated with a NULL byte, the client needs to transmit the destination domain name and then end it with another NULL byte. This protocol applies to 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
When utilizing SOCKS4A, a web server must analyze the DSTIP data present in the incoming packet.
If a request is made within the range of x and 0.0.0.0.x and the representation address lacks 0, the server should extract the domain name of the transmitted data. Subsequently, the server is obligated to resolve the domain name found in the incoming packets and, when feasible, execute a connection to the host.
SOCKS5
This protocol can be viewed as an extension of the SOCKS4 protocol providing additional authentication options. Moreover, it includes dynamic DNS support for both IPv6 and UDP. The primary connection request involves the following stages:
- Upon the client connecting, a greeting is sent which presents a list of supported authentication methods.
- The server then selects one or sends a failure response if none of the offered methods are acceptable.
- Based on the authentication method chosen, several messages may now be exchanged between the client and server.
- The client then sends a connection request that resembles SOCKS 4,
and the server responds similarly to SOCKS 4.
The supported authentication stages and types are as follows:
0x00: No authentication
0x01: GSSAPI
0x02: Username/Password
0x03–0x7F: methods assigned by IANA
0x80–0xFE: methods reserved for private use
The first response from the client is as follows:
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
Choice made by the server:
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 authentication process following this stage is method-dependent. For information on username/password authentication (method 0x02), refer to RFC 1929.
Client request for username/password authenticate:
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’s response to username/password authenticate:
field 1: version, 1 byte
field 2: status code, 1 byte.
0x00 = success
any other value = failure, connection must be closed
Client’s connection request:
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
We have analyzed the connection requests of SOCKS4, SOCKS4a, and SOCKS5 protocol types to a server and the authentication process of the SOCKS5 protocol. Despite its resemblance to a regular HTTP or HTTPS connection, it has a more intricate structure.
The SOCKS protocol may offer greater security than HTTPS, depending on the context of its use. As we are aware, HTTPS is not infallible. Similarly, the SOCKS protocol is also not without flaws. These communication protocols vary from one another based on their respective usage areas.
Various Clients That Support SOCKS
3proxy: It is a SOCKSv4/4a/5 proxy that supports comprehensive UDP requests for Unix, Linux, and Windows, as well as IPv6. Additionally, it allows for chained proxy requests and the ability to switch between different proxy types.
Antinat: It is an extended library for both SOCKS server and client. It supports SOCKS 4/4a/5 and is equipped with advanced authentication, CHAP, XML firewall, a Win32 server component, and UDP. IPv6 support is also available, albeit in a more experimental form.
Dante: It’s an alternative client for SOCKS that provides a secure and convenient network connection, limiting connections to server-to-client only.
Sun Java Systems Web Proxy Server (iPlanet Web Proxy Server): It is a SOCKS server that includes HTTPS and NSAPI I/O filters, as well as dynamic reconfiguration capabilities.
WinGate: It’s an advanced multiprotocol that supports SOCKS 4/5 on Windows. UDP offers multiple attempts for HTTP proxy with GSSAPI support.
In this article, we discussed the SOCKS protocol, including its history, development, communication phases, and supported software. I hope it was useful for you, see you in the next article.
You might be interested in: What is DNS zone transfer?
