Security Technologies for the World Wide Web, Second Edition

3.4     Circuit-level gateways

The idea of an application gateway is fundamentally different from a packet filter (i.e., a static or dynamic packet filter). This is equally true for circuit-level gateways. In essence, a circuit-level gateway is a proxy server for TCP ^[9] (i.e., it is typically located and running on the firewall of a corporate intranet and it relays TCP connections).

More specifically , a circuit-level gateway does the following three things when a client wants to establish a TCP connection to a server:

1. It receives the TCP connection establishment request that is sent out by the client (because the client is configured to make use of the circuit-level gateway).

2. It authenticates and possibly authorizes the client (or the user behind the client).

3. It establishes a second TCP connection to the server on the client s behalf .

After having successfully established the second TCP connection, the circuit-level gateway simply relays application data forth and back. ^[10] As such, it does not interfere with the data stream. This differentiates a circuit-level gateway from an application-level gateway or proxy server that is able to understand the application protocol employed by the two endpoints of the connection. What this basically means is that the circuit-level gateway need not understand the application protocol in use. This simplifies the implementation and deployment of circuit-level gateways considerably.

The most important circuit-level gateway in use today is SOCKS. ^[11] It 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, most Web browsers (e.g., Microsoft s Internet Explorer) are socksified clients and issue SOCKS calls that are transparent to their 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 was originally proposed in [14]. 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 3.1. This is sufficiently easy to be used on a large scale.

The design goal of SOCKS was to provide a general framework for TCP/IP applications to securely use (i.e., 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 a 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 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 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 server. As we saw previously, 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 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. 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 server (without looking into or interpreting the data stream).

The original SOCKS implementation was refined into a SOCKS package and a protocol that is widely deployed and commonly referred to as SOCKS Protocol version 4, or SOCKS V4. After the successful deployment of SOCKS V4, the IETF chartered an Authenticated Firewall Traversal (AFT) WG to ˜ ˜start with the SOCKS system described in [14], and to ˜ ˜specify a protocol to address the issue of application-layer support for firewall traversal in 1994. ^[12] The major result of the IETF AFT WG was the specification of the SOCKS protocol version 5 (SOCKS V5) in March 1996 [15]. ^[13] 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.

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 meet 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 [16] and Kerberos V5 GSS-API authentication in [17]. 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.

• 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 [15]. 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 above. 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 backward compatibility.

In summary, a circuit-level gateway (e.g., a SOCKS server) provides an interesting technology and possibility to have applications and application protocols securely traverse a firewall. A clear advantage of circuit-level gateways is their generality, meaning that a circuit-level gateway can act as a proxy server for any application (not just one). Circuit-level gateways are particularly useful for applications for which application-level gateways (i.e., proxy servers) do not exist or are conceptually hard to design and implement. For example, an application protocol that is hard to deal with (using packet-filtering technologies and application-level gateways) is the Internet Inter-ORB Protocol (IIOP) that is used in environments and applications that conform to the Common Object Request Broker Architecture (CORBA). The difficulty stems from the fact that the IIOP makes use of UDP and dynamically assigned port numbers . Against this background, a group of vendors have jointly specified the use of SOCKS V5 to have IIOP communications securely traverse a firewall. ^[14] This is a technology that we will likely see deployed in the future. The generality of circuit-level gateways, however, also comes with some disadvantages. For example, a SOCKS server is not able to scan application data for specific commands or executable content (e.g., Java applets or ActiveX controls). Consequently, if a configuration must be optimized for maximum security, the use of application-level gateways is still the preferred option.

^[9] This statement is not completely true, as contemporary circuit-level gateways also are able to handle UDP-based application protocols. This will be explained later in this chapter.

^[10] Note that the only difference between a circuit-level gateway and a simple port forwarding mechanism is that with a circuit-level gateway, the client must be aware of the intermediate system, whereas in the case of a simple port-forwarding mechanism, the client need not be aware and may be completely oblivious of the existence of the intermediary. Also, a circuit-level gateway is generic, and any TCP connection can be handled by the same gateway (if enabled in its configuration). Contrary to that, a port-forwarding mechanism is usually specific to a given service, meaning that all qualifying TCP segments are forwarded to a specific port of a server.

^[11] http://www.socks.nec.com

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

^[13] At the time of this writing, an updated version of the SOCKS Protocol version 5 specification is published as an Internet draft.

^[14] http://www.socks.nec.com/corba-firewall.pdf