Internet & Intranet Security

15.4 FIREWALL TUNNELING

As of this writing, SSL and TLS in general, and HTTPS in particular, are widely used and deployed on the Internet and the WWW. Unfortunately, the protocols do not easily interoperate with application gateways (i.e., circuit-level gateways and application-level gateways). Note that an SSL or TLS connection is always established on an end-to-end basis, and that any application gateway or proxy server running at the firewall (between the client and the origin server) must be considered to be a "man-in-the-middle." Also note that different protocols generally have different requirements for proxy servers.

In general, an application protocol can either be proxied or tunneled through a proxy server [20]:

• When we say that an application protocol is being proxied, we actually mean that the corresponding proxy server is aware of the specifics of the protocol and can understand what is happening on the protocol level. This allows such things as protocol-level filtering, access control, accounting, and logging. Examples of protocols that are usually proxied include Telnet, FTP, and HTTP.

• Contrary to that, we say that an application protocol is being tunneled when we actually mean that the corresponding proxy server (which is basically acting as a circuit-level gateway) is not aware of the specifics of the protocol and cannot understand what is happening on the protocol level accordingly. It is simply relaying, or "tunneling," the data between the client and the server, and does not necessarily understand the protocol being used. Consequently, it cannot perform such things as protocol-level filtering, access control, and logging to the same extent as is possible for a full-fledged proxy server. Examples of protocols that are usually tunneled by proxy servers or circuit-level gateways include SSL-enhanced protocols, such as HTTPS, as well as the IIOP used in CORBA environments.

In an early attempt to address the problem of having SSL/TLS or HTTPS traffic going through a proxy-based firewall, Ari Luotonen from Netscape Communications proposed an SSL Tunneling Protocol that basically allows an HTTP proxy server to act as a tunnel for SSL-enhanced protocols. The protocol allows an SSL (or HTTPS) client to open a secure tunnel through an HTTP proxy server that resides on the firewall. When tunneling SSL, the proxy server must not have access to the data being transferred in either direction (for the sake of confidentiality). The proxy server must merely know the source and destination addresses (IP addresses and port numbers), and possibly, if the proxy server supports user authentication, the name of the requesting user. Consequently, there is a handshake between the client and the proxy server to establish the connection between the client and the remote server through the intermediate proxy server. To make the SSL tunneling extension be backward compatible, the handshake must be in the same format as normal HTTP/1.0 requests, so that proxy servers without support for this feature can still determine the request as impossible for them to service, and provide proper error notifications. As such, SSL tunneling is not really SSL specific. It is rather a general way to have a third party establish a connection between two endpoints, after which bytes are simply copied back and forth by this intermediary.

Using the SSL Tunneling Protocol, the client connects to the proxy server and uses the CONNECT method to specify the hostname and the port number to connect to (the hostname and port number are separated by a colon). The host:port part is then followed by a space and a string specifying the HTTP version number (e.g., HTTP/1.0 or HTTP/1.1), and the line terminator. After that, there is a series of zeros or more of HTTP request header lines, followed by an empty line. After this empty line, if the handshake to establish the connection was successful, SSL can actually transfer data. Consequently, an SSL tunneling sequence may look as follows:

CONNECT www.esecurity.ch:443 HTTP/1.0 User-agent: Mozilla/4.05 [en] (WinNT; U) ... SSL data ...

The SSL tunneling handshake is freely extensible using arbitrary HTTP/1.0 headers. For example, to enforce client authentication, the proxy may use the 407 status code and the Proxy-authenticate response header to ask the client to provide some authentication information to the proxy. Consequently, the SSL tunneling sequence looks as follows:

HTTP/1.0 407 Proxy authentication required Proxy-authenticate: ... ... SSL data ...

In this case, the client would send the required authentication information in a message that looks as follows:

CONNECT www.esecurity.ch:443 HTTP/1.0 User-agent: Mozilla/4.05 [en] (WinNT; U) Proxy-authorization: ... ... SSL data ...

Note that the CONNECT method provides a lower level function than the other HTTP methods. Think of it as some kind of an "escape mechanism" for saying that the proxy server should not interfere with the transaction, but merely serve as a circuit-level gateway and forward the data stream. In fact, the proxy server should not need to know the entire URL that is being requested–only the information that is actually needed to serve the request, such as the hostname and port number of the origin Web server. Consequently, the proxy server cannot verify that the protocol being spoken is really SSL, and the proxy server configuration should therefore explicitly limit allowed (tunneled) connections to well-known SSL ports, such as 443 for HTTPS or 563 for NNTPS (the port numbers are assigned by the IANA). As of this writing, SSL tunneling is supported by most HTTP proxy servers and browsers that are commercially available, including, for example, Netscape Navigator and Microsoft Internet Explorer.

The primary use of SSL tunneling is to let internal users within a corporate intranet access external HTTPS servers on the Internet (in this case, it is seldom necessary to check the destination port number, because outbound HTTP connections are allowed in most security policies). Nevertheless, SSL tunneling can also be used in the opposite direction, namely, to make internal HTTPS servers visible and accessible to the outside world (to the users located on the Internet). In this case, however, the proxy server acts as an inbound proxy^[11] for the SSL data traffic. What this basically means is that HTTPS connections originating from the outside world are simply relayed by the inbound proxy to the internal HTTPS servers, where the requesting users should be strongly authenticated. Therefore, the internal Web servers must implement the SSL or TLS protocol. Unfortunately, this is not always the case and most internal Web servers are still not SSL or TLS-enabled (and do not represent HTTPS servers accordingly). In this case, the inbound proxy must authenticate the requesting clients and connect them to the appropriate internal Web servers. To make this possible (and to make these servers visible to the outside world), several SSL gateways or SSL proxy servers have been developed and are being marketed today. For example, a group of researchers from the DEC Systems Research Center proposed the use of a combination of SSL client authentication (at the inbound proxy) and URL rewriting techniques in a technology called "secure Web tunneling" [21]. Since then, several products have been developed that implement similar ideas. One example is the Trusted Entry Security Server (TESS) jointly developed by two Swiss companies.^[12]

A final word is due to the fact that the use of SSL, TLS, or any other transport layer security protocol to secure (i.e., encrypt) HTTP data traffic also negatively influences the usefulness of proxy servers for caching. If a resource is encrypted end-to-end, it is encrypted in a way that is useful only for the server and one particular client (i.e., the client that has requested the resource and holds the corresponding session key). Consequently, there is no use in caching the encrypted resource for other clients.

^[11]In the literature, inbound proxies are called reverse proxies most of the time. In this book, however, we use the term "inbound proxy," as there is no reverse functionality involved. In fact, a reverse proxy is doing nothing differently than a normal proxy server. The only difference is that it primarily servers inbound connections (instead of outbound connections).

^[12]http://www.tess.ch