6.4 Firewall traversal
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
with application gateways (i.e.,
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
to be a man-in-the-middle. Also note that different protocols
have different requirements for proxy servers. Consequently, firewall traversal represents an important problem area for SSL and TLS.
In general, an application protocol can either be
or tunneled through a proxy server:
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
. It is simply relaying, or tunneling, the data between the client and the server, and does not
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 intranet environment, outbound SSL/TLS connections are often tunneled, whereas inbound SSL/TLS connections are proxied most of the times.
6.4.1 SSL/TLS tunneling
In an early attempt to address the problem of having SSL or HTTPS traffic going through a proxy-based firewall, Ari Luotonen from Netscape Communications proposed an SSL Tunneling Protocol that allows an HTTP proxy server to act as a tunnel for SSL-enhanced protocols. The protocol allows an SSL (or HTTPS) client to
a secure tunnel through an HTTP proxy server that resides on a 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
), and possibly, if the proxy server supports
of the requesting user. Consequently, there is a handshake between the browser and the proxy server to establish the connection between the browser 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
, so that proxy servers without support for this feature can still determine the request as
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
back and forth by this intermediary.
The SSL Tunneling Protocol is simple and straightforward. It uses a special HTTP method (i.e., CONNECT) and requires the browser to use this method to connect to the remote server.
, the browser 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
part is then followed by a space and a string specifying the HTTP version number (e.g., HTTP/1.0) and the line terminator. After that, there is a series of zero or more HTTP request header lines, followed by an empty line. Consequently, the first line of a CONNECT request message may look as
CONNECT www.esecurity.ch:443 HTTP/1.0
After having received this message, the proxy server ties to establish a TCP connection to port 443 of
If the server accepts the connection, the proxy server acts as a relay between the browser and the server. At this point in time, the browser and the server can start using SSL or TLS to establish a secure connection between them.
The SSL tunneling handshake is
extensible using arbitrary HTTP/1.0 headers. For example, to enforce client authentication, the proxy may use the 407 status code and the
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 Proxyauthentication
required Proxy-authenticate: ...
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
Note that the CONNECT method provides a lower level function than the other HTTP
. 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
”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 Microsoft Internet Explorer, Opera, and Netscape Navigator.
6.4.2 SSL/TLS proxy servers
As mentioned above, 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
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
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
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/TLS gateways or SSL/TLS proxy servers have been developed and are being marketed today. For example, a
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
. A similar technology to access internal Web servers has been developed and complemented with a one-time password system by a group of researchers at AT&T Laboratories .
A final word is necessary due to the fact that use of the SSL and TLS protocols to secure (i.e., encrypt) HTTP data traffic also negatively influences the
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.
Meanwhile, the HTTP CONNECT method has become part of the HTTP specification.
In the literature, inbound proxies are called
most of the time. In this book, however, we use the
, as there is no reverse functionality involved. In fact, a reverse proxy is doing nothing differently than a normal proxy servers. The only difference is that it primarily serves inbound (instead of outbound) connections.