9.2 SOCKS

Team-Fly

SOCKS is a circuit-level gateway that follows a customized client approach, meaning that it requires customizations and modifications to the client software (i.e., no change is usually required to user procedures). More precisely, SOCKS requires modifications either to the client software or the TCP/IP stack to accommodate the interception at the firewall between the client and the server:

A client that has been modified to handle SOCKS interactions is commonly referred to as a socksified client. Following this terminology, Netscape Navigator and Microsoft Internet Explorer are both socksified clients, as they accommodate interactions with a SOCKS server. A socksified client issues SOCKS calls that are transparent to the users.
Socksified TCP/IP stacks are also available, which may obviate the need for client software modifications.

In either case, the SOCKS server resides at the firewall and interacts with the socksified clients or TCP/IP stacks. There are no further changes required for the servers that may reside either on the Internet or intranet.

SOCKS and the original SOCKS protocol for communications between a socksified client and a SOCKS server were originally developed by David and Michelle Koblas and proposed in a paper at the 1992 USENIX Security Symposium [1]. The original implementation consisted of two components: a SOCKS server or daemon (i.e., sockd) and a SOCKS library that can be used to replace regular Sockets calls in the client software. More specifically, the application developer has to recompile and link the client software with a few preprocessor directives to intercept and replace the regular TCP/IP networking Sockets calls with their SOCKS counterparts, as summarized in Table 9.1. This is sufficiently easy to be used on a large scale.

Table 9.1: Sockets Calls and SOCKS Counterparts
SOCKS Call	Socket Call

`Rconnect`	`connect`
`Rbind`	`bind`
`Rlisten`	`listen`
`Rselect`	`select`
`Rgetsockname`	`getsockname`
`Raccept`	`accept`

The design goal of SOCKS was to provide a general framework for TCP/IP applications to securely use (and traverse) a firewall. Complying with these design goals, SOCKS is independent of any supported TCP/IP application protocol. When a socksified intranet client requires access to an destination server on the Internet, it must first open a TCP connection to the appropriate port on the SOCKS server residing on the firewall system (the SOCKS server conventionally listens at TCP port 1080). If this first TCP connection is established, the client uses the SOCKS protocol to have a second TCP connection to the destination server be established by the SOCKS server.

The SOCKS protocol used between the socksified client (i.e., the client using the SOCKS library routines) and the SOCKS server basically consists of the following two commands:

The CONNECT command takes as arguments the IP address and port number of the destination server, as well as a username. It basically requests that the SOCKS server establishes a TCP connection to the given IP address and port number.
The BIND command takes as arguments the client IP address and a username. It is used only in protocols that require the client to accept connections back from the destination server. As we have seen in Chapter 8, FTP is an example of such a protocol (since it requires the client to accept a data connection from the server).

In either case, the username is a string passed from the requesting client to the SOCKS server for the purposes of authentication, authorization, and accounting.

After having received a request (i.e., a CONNECT and/or BIND command), the SOCKS server evaluates the information provided by the client. The evaluation is performed against a sockd configuration file that may include a ruleset. Each rule in the set either permits or denies communications with one or several systems (the syntax of the rules is specified in [1]). In either case, the SOCKS server sends a reply back to the client. Among other things, the reply includes information indicating whether the request was successful. Once the requested second connection is established, the SOCKS server simply relays data back and forth between the client and the destination server (without looking into or interpreting the data stream).

The original SOCKS implementation of [1] was further refined into a SOCKS package and a protocol that is widely deployed and commonly referred to as SOCKS protocol version 4, or SOCKS V4. Many client software packages have been socksified in the past. For example, most Web browsers we use today (e.g., Netscape Navigator and Microsoft Internet Explorer) have been socksified. Figures 9.2 and 9.3 illustrate the corresponding manual proxy configuration and proxy settings menus of Netscape Navigator and Microsoft Internet Explorer. In either case, the browser is configured to make use of a SOCKS server that runs on port 1080 of a system with the host name socks.esecurity.ch.

click to expand
Figure 9.2: Manual Proxy Configuration menu of Netscape Navigator. © 2001 Netscape Communications Corporation.

click to expand
Figure 9.3: Proxy Settings menu of Microsoft Internet Explorer. © 2001 Microsoft Corporation.

After the successful deployment of SOCKS V4, the IETF chartered an Authenticated Firewall Traversal (AFT) WG to "start with the SOCKS system described" in [1], and to "specify a protocol to address the issue of application-layer support for firewall traversal" in 1994.^[3] The major result of the IETF AFT WG was the specification of the SOCKS protocol version 5 (SOCKS V5) in March 1996 [2].^[4] As such, SOCKS V5 has been submitted to the Internet standards track as a Proposed Standard. It is possible and very likely that the protocol will become an Internet Standard in the future.

As compared with SOCKS V4, SOCKS V5 provides some additional features. These features are related to user authentication, communication security, UDP support, and extended addressing schemes:

In SOCKS V4, user authentication is relatively simple and straightforward. It basically consists of a username that is sent from the socksified client to the SOCKS server as part of the CONNECT or BIND method. In addition to this simple authentication scheme, SOCKS V5 supports a handshake between the client and the SOCKS server for authentication method negotiation. The first message is sent by the client to the SOCKS server. It declares the authentication methods the client is currently able to support. The second message is sent from the SOCKS server back to the client. It selects a particular authentication method according to the SOCKS server's security policy. If none of the methods declared by the client meets the security requirements of the SOCKS server, communications are dropped. After the authentication method has been negotiated, the client and SOCKS server start the authentication process using the chosen method. Two authentication methods are specified in corresponding RFC documents: password-based authentication in [3] and Kerberos V5 GSS-API authentication in [4].^[5] The approach for use of GSS-API in SOCKS V5 is to authenticate the client and server by successfully establishing a security context. This context can then be used to protect messages that are subsequently exchanged. Prior to use of GSS-API primitives, the client and server should be locally authenticated and have established default GSS-API credentials.
Depending on the underlying authentication methods implemented via GSS-API, a client can negotiate with the SOCKS server about the security of subsequent messages. In the case of Kerberos V5, either integrity and/or confidentiality services are provided for the rest of messages, including the client's requests, the SOCKS server's replies, and all application data. Note that this feature is particularly well suited for use by reverse proxy servers, because it supports data encryption between clients (on the Internet) and the SOCKS server.
As mentioned, SOCKS V4 is only able to handle TCP applications. Unfortunately, an increasingly large number of TCP/IP applications are making use of UDP (e.g., applications that make use of real-time and/or multicast communications). Against this background, the SOCKS protocol has been extended to additionally provide support for UDP. More specifically, a new method, called UDP ASSOCIATE, has been added to the SOCKS V5 protocol specification [2]. The UDP ASSOCIATE request sent from the client to the SOCKS server is used to establish an association within the UDP relay process to handle UDP datagrams. According to this association, the SOCKS server relays UDP datagrams to the requesting client. Obviously, this approach is conceptually similar to stateful inspection or dynamic packet filtering as discussed in Chapter 8. The UDP association terminates when the TCP connection that the UDP ASSOCIATE request arrived on terminates. As a result, the SOCKS V5 library can now be used to socksify both TCP- and UDP-based applications.
Finally, SOCKS V5 supports DNS names and IP version 6 addresses in addition to normal IP version 4 addresses.

Because of their fundamental differences, the SOCKS V5 protocol specification does not require any provision for supporting the SOCKS V4 protocol. However, it is a simple matter of implementation to enable SOCKS V5 servers to communicate with V5 and V4 clients. In fact, most SOCKS V5 servers that are available today provide this backward compatibility.

^[3]http://www.ietf.org/html.charters/aft-charter.html

^[4]At the time of this writing, an updated version of the SOCKS protocol version 5 specification is published as an Internet-Draft.

^[5]The term GSS-API will be explained when we discuss the Kerberos authentication system and its application programming interface (API) in Section 16.2.

Team-Fly