Secure Web tunneling

Martín Abadi, Andrew Birrell, Raymie Stata, and Edward Wobber

Systems Research Center, Digital Equipment Corporation,
130 Lytton Avenue, Palo Alto, CA 94301, USA

Abstract
The boundary of an organization does not always coincide with its firewall. A member of an organization that is outside the firewall may wish to access internal Web services with the same ease and security that are common within the firewall. At the same time, the firewall should still be able to perform adequate access control, logging, and auditing. In this paper, we describe a new technique for secure Web tunneling, which permits the desired outside access to internal Web services. We argue that this technique is preferable to alternatives such as special firewall configurations, IP tunneling, and reverse proxies. We describe an implementation of Web tunneling that relies mostly on common, off-the-shelf components.

Keywords
Tunnel; Firewall; Security; Authentication; Privacy

1. Introduction

As Needham noted recently, it is now common to say that security considerations within an organization are different from those between organizations [Nee97]. Each organization may have a private network (an Intranet), which uses the IP protocol like the rest of the Internet, but which is protected from the rest of the Internet by a firewall [CB94]. Within an Intranet, trust often prevails; security may rely more on detection and punishment of abuses than on preventive measures, like the use of elaborate cryptographic protocols. The firewall can prevent tampering with private resources by unauthorized, outside parties. It can also restrict and track the movement of data from the Intranet to the rest of the Internet.

Unfortunately, the boundary of an organization does not always coincide with its firewall. For example, a trusted member of an organization may be travelling, and may need to access the organization's Web servers using a public terminal. In these circumstances, one would want the firewall to become invisible to the user, providing the illusion that the user is within the firewall rather than outside, and permitting seamless Web access to the rest of the organization. However, the firewall should not simply evaporate: it remains crucial for the detection of attacks, that is, for auditing.

In this paper, we describe a new technique for Web tunneling, which allows a principal located outside a firewall to access Web resources in the Intranet that the firewall protects. The main features of our technique are as follows.

An important aspect of our technique is that it operates at the HTTP level. In general, a firewall may allow traversal by IP packets, TCP streams, HTTP requests and responses, or by data from other protocols. Traversal by lower-level protocols may provide more generality. On the other hand, when traversal takes place at the application layer, we can take advantage of knowledge about the application semantics for access control, logging, and auditing. In particular, when the application is the HTTP protocol, we may log or restrict HTTP requests, rather than lower-level IP packets.

Our technique does not immediately support connections across several firewalls controlled by different organizations. This restriction simplifies our implementation. More importantly, it simplifies our security model. When a principal from an organization A is inside the firewall of another organization B, it is not clear that adequate confidentiality guarantees can be provided at all; in particular, B could legitimately demand to read the confidential information from A that goes through its firewall.

There exist other mechanisms that partially address the needs for Intranet Web access by trusted principals through firewalls; several of them are discussed in the next section. Section 3 describes our design; Sections 4 concerns options for authentication. Section 5 explains the security properties achieved in our design. Section 6 describes our implementation and our experience to date. Section 7 concludes.

2. Related work  

As mentioned above, there exist several mechanisms that provide Intranet Web access through firewalls. However, these mechanisms have drawbacks that make them inadequate as solutions for our problem.

3. Design  

In this section we describe how our technique for secure Web tunneling works. We start with a discussion of the assumptions that motivate some aspects of our design.

3.1. Assumptions

The recent history of the Internet has seen Web browsers, HTTP, and HTML replace a wide variety of proprietary applications, protocols, and formats. Web browsers are quickly becoming a ubiquitous platform for network applications. This ubiquity makes it possible, for example, to access the public Internet through an ISP from a laptop in a hotel room, or by using a rental Internet computer such as the ones available in cybercafes, or by using a computer at a friend's house.

The development of the Internet has not solved the problem of secure access to an Intranet. In fact, new forms of Internet access introduce new constraints: in many circumstances (e.g., at a cybercafe) the principal that wishes to access the Intranet is not able to install software into the client computer being used.

Because of those constraints, our technique requires only that the client machine be equipped with a standard Web browser (such as Netscape Navigator or Internet Explorer). This Web browser should be capable of using HTTPS, the secure variant of HTTP that relies on the SSL protocol for authentication and confidentiality. The details of SSL are not important for our purposes, however, so SSL could be replaced with other protocols. Furthermore, the use of HTTPS does not imply the need for a pervasive public-key infrastructure; the current infrastructure suffices.

The client should be somewhat trustworthy, at least while it is in use. This assumption is basically unavoidable, since a malicious client could publish sensitive data it has retrieved from the Intranet. The need for a trustworthy client could be reduced in a variety of ways (e.g., [ABKL93]). We prefer not to complicate our system with those precautions, assuming some trust in the client. In practice, this assumption implies that the client should run a browser with no known security flaws, and that it should be in the physical control of a reputable party.

This assumption may seem dubious when the client is rented casually, as in a cybercafe. In such a situation, the assumption comes down to a belief that a respectable business will take reasonable steps to ensure the integrity of the operating system and browser software on the computers that it offers for rent. Users with particularly valuable or sensitive Web transactions might decide not to accept the risk inherent in public rental computers.

Whereas the client should be somewhat trustworthy, we make no assumptions about its connection to the Internet. In particular, our technique for secure Web tunneling protects against a malicious ISP.

3.2. The Web tunnel and its operation

The core of our system is a specialized server, which we call the Web tunnel. This server controls external access to Intranet Web pages. It acts as inbound proxy for all requests targeted at the protected Intranet.

The Web tunnel executes within the protection of the Intranet's firewall and is logically part of the firewall. It can make HTTP connections to servers inside the firewall, and the firewall permits HTTP and HTTPS connections to the Web tunnel from the outside. We do not assume or prohibit the Web tunnel being on the same actual computer as the firewall, nor there being just one firewall computer, nor there being just one Web tunnel per Intranet.


 
Fig. 1.  Structure of the Web tunnel.
Structure of the Web tunnel

As shown in Fig. 1, the Web tunnel has three main components, the authenticator, the redirector, and the proxy:

1.
The authenticator produces material that is used to authenticate the client to the proxy.

2.
The redirector processes incoming HTTP requests, and maps HTTP URLs to HTTPS URLs. The redirector returns these HTTPS URLs to the client in HTTP redirect responses.

3.
Upon receipt of one of these HTTPS URLs, the client establishes a secure connection to the proxy for transmitting the redirected request. The proxy relays the original request as HTTP on the Intranet, and returns any response over the secure connection back to the client.

The following scenario explains the use of these three components. Suppose that Tom is a trusted person who works for the Acme company. When Tom wishes to access Acme's Intranet from outside, he proceeds as follows:

Note that the Web tunnel has the cleartext of the request and the response; moreover, these are not broken into difficult-to-interpret lower-level packets. Therefore, the Web tunnel can read and understand the request and the response, so it can perform adequate access control, logging, and auditing. In particular, a firewall administrator could configure the Web tunnel to prevent external access to some parts of the Intranet. In the jargon, the Web tunnel is an application-level gateway.

3.3. Redirection  

Our method relies on a mechanism whereby a redirected URL causes a browser to contact the proxy component of the Web tunnel. There are several possible implementations of this mechanism. In one implementation, the redirected URL is identical to the original URL except for a change from http to https; the browser is configured to use the tunnel as proxy server for the redirected URL; and the tunnel has the keys necessary for impersonating all internal Web servers. A more sophisticated implementation, which we adopt, is the following: For example, the HTTP URL http://hr.acme.com/foo.htm may yield the HTTPS URL https://tunnel.acme.com/hr.acme.com/foo.htm. When the proxy component of the Web tunnel receives a request for such a redirected URL, it recovers the original URL and proxies the request to the original URL's server.

This construction for the redirected URL has the desirable feature that the URL is transportable across the firewall, in the following sense. Suppose that a browser has fetched a Web page through the Web tunnel. When the browser displays the page, it will normally show the redirected URL as the URL (location) of the current page. The user can copy this URL and communicate it (for example, by e-mail) to a user inside the firewall. The user inside the firewall will be able to use this URL, without editing it. A request for this URL will involve the Web tunnel, as usual, but the proxy need not authenticate the user because it can determine that the origin of the request is an IP address inside the firewall.

An HTTP request sent by the browser to the redirector may leak some sensitive information, for example a compromising name of a Web page. There is nothing the Web tunnel can do to prevent a user from disclosing sensitive information, but the Web tunnel should not encourage or facilitate this disclosure. Therefore, the redirector should refuse to redirect sensitive HTTP requests. We rely on administrative policy to identify those sensitive requests. Note that, after an initial HTTP request, the browser may issue only HTTPS requests. This will happen, for example, if each subsequent request is for a relative URL found in a page obtained through HTTPS. Unlike the initial request, these subsequent requests do not go through the redirector and need not be restricted.

Our redirection mechanism, like the rest of our system, is designed to work with existing software, in particular with existing browsers. The redirector component of the Web tunnel would be completely unnecessary if we could modify existing browsers, or if we could dictate the use of special browsers. Specifically, suppose that we could extend the proxy configuration facilities of browsers, allowing browsers to communicate with proxies over HTTPS. A browser could then access the proxy component of the Web tunnel directly, over HTTPS, without first contacting the redirector.

3.4. HTML rewriting

When the proxy component of the Web tunnel returns HTML to the client, it maps Intranet URLs found in the HTML to HTTPS URLs, in flight. This remapping saves some communication, namely exchanges with the redirector. It need only be done for absolute URLs, since relative URLs are already interpreted in the context of an HTTPS parent.

Suppose that all Intranet URLs are mapped to HTTPS URLs in this manner. Then, after browsing starts at a suitable location (e.g., one whose URL does not leak sensitive information), all URLs and contents reached from that point are encrypted as they travel across the Internet.

In the context of our redirection method, some other HTML rewriting must take place for relative URLs that begin with / (which roughly means ``the current host''). When an HTML piece contains such a URL, the proxy rewrites it to an appropriate absolute HTTPS URL.

4. Authentication options  

In our system, there is no direct authentication between a user outside the firewall and the Intranet Web servers that the user accesses. Instead, there is authentication between the browser and the proxy component of the Web tunnel. The browser authenticates the proxy to prevent spoofing of Web pages and man-in-the-middle attacks, and displays the identity of the proxy to the user. On the other hand, the proxy determines the identity of the user of the browser in order to decide which requests should be granted. Thus, authentication is mutual; however, its two directions are rather different from one another.

We use the SSL protocol with standard X.509 certificates for authentication of the proxy. As noted above, the browser must trust the certification authority that signs the proxy's certificate. Most browsers provide support for certificate management, so this trust relationship can be configured manually. The proxy may also have a certificate signed by one of the several certification authorities (such as Verisign) that browsers trust by default.

Several options are available for authenticating the user. One attractive possibility is that the user has a piece of hardware that holds a private key and a personal certificate. This piece of hardware may be in particular a smart-card, a laptop, or a home computer. In this case, the user can rely on the private key and the personal certificate for authentication. However, despite much recent progress in the deployment of smart-cards and public-key cryptography, we do not wish to require their use, because they are not yet pervasive. Therefore, our system also supports user authentication without public-key cryptography.

In order to obtain authentication material when lacking a private key, the user first performs an exchange with the authenticator component of the Web tunnel. This exchange is automatically started whenever the user attempts to access a URL through the Web tunnel without presenting valid authentication material. The exchange takes place over an SSL connection where the Web tunnel is authenticated, but not the user; this SSL connection also provides confidentiality. On top of this connection, the user gives a proof of identity to the Web tunnel.

In any case, as a result of the exchange with the authenticator, the user obtains some authentication material that it can present to the proxy. Since the connection to the proxy provides secrecy, in our system this material takes the form of a short-term password. This password can be presented to the proxy through HTTP basic authentication [BLFN96] or as a cookie [KM97]. In either case, the browser can store the password and recall it when necessary, without user intervention.

Each password expires after a short period of time. Upon the expiration of a password, the user returns to the authenticator to obtain a new password.

5. Guarantees  

The previous sections describe the workings of the Web tunnel; this section summarizes the security properties that it achieves. The main theme of these properties is that Web accesses that traverse a firewall through a Web tunnel have the same security characteristics as Web accesses within the firewall. In addition, the firewall retains the ability to provide protection at the HTTP level.

In more detail, when a principal accesses internal Web services through the tunnel, the following security properties hold.

These properties are not provided in an absolute sense. They depend on the security of the underlying components, such as the browser, the operating system, and the cryptography used for authentication. We treat these underlying components as black boxes; other vendors and researchers are working actively on their security.

6. Implementation and experience  

We have a working implementation of the Web tunnel. It consists of two separate servers. The first server is an Apache HTTP server [Apa] with an additional module that implements redirection. Note that Apache normally allows for redirection of only locally targeted requests, but in our case requests are aimed elsewhere, so we need special code to intercept and redirect them. The second server is an Apache-SSL server that implements the authenticator and the proxy. In both servers, we run with only our own Apache modules — eliminating various other modules that come as part of the Apache distribution. Our modifications and additions to the Apache system are relatively minor; they consist of some code for HTML rewriting and about 1300 lines of other C code.

For user authentication, we support the three options presented in Section 4: the user may have a private key, a password, or a Digital Pathways SecureNet Key device. In what follows, we describe our use of SecureNet Key devices in some detail; the other two authentication methods are relatively straightforward.

A SecureNet Key is a small, hand-held device with a keypad and an LCD display; when a number is entered through the keypad, the LCD display shows the result of applying a function to the input and to a secret embedded in the device. In order to obtain authentication material, the user accesses a particular HTTPS page provided by the authenticator component of the Web tunnel. This page contains a simple HTML form that asks for the user's identity. In response to the submission of this form, the user is shown a challenge/response form generated by the authenticator. The form includes a challenge, which the user enters into the SecureNet Key; then the SecureNet Key provides a response, which the user enters into the form. Upon processing this form, the authenticator validates the SecureNet Key response, and if successful returns a cookie that the user will present when communicating with the proxy component of the Web tunnel.

The cookie produced by the authenticator contains several security-relevant fields.

The hash component of a cookie prevents forgery. However, if an attacker could steal a cookie and could also spoof the IP address recorded in the cookie, then the attacker would be able to access the Intranet until the cookie expires. To prevent this attack, we use SSL to encrypt cookies as they travel between browser and server. Our cookies are marked as ``secure''; this tells the browser that they must not be transmitted over insecure channels.

A browser can be attacked over the Internet, or more simply by an intruder with physical access to the computer on which the browser runs. The expiration of cookies, as described above, limits those attacks. Still, one may be concerned about the sensitive state (including cookies) that might accumulate in the context of a public-access browser over time. A straightforward means for flushing this state is necessary to make public-access browsing more practical in the future.

In our implementation, the timeouts for cookies are configurable. We have been using rather conservative values: 15 minutes idle-time limit, and expiration after 1 hour. We chose these timeouts partly because our SSL implementation allows weak (40-bit) encryption. According to our experience thus far, these timeouts are probably too short to be comfortable; the user needs to authenticate frequently, with some inconvenience. We can probably relax these timeouts for sessions that use strong (128-bit) encryption.

Our implementation has been operational for a few months. In this period, several employees and consultants have been accessing our company's Intranet Web servers through the Web tunnel across a firewall. The tunnel has permitted not only standard Web-browsing, but also reading and writing of electronic mail in the context of a new, Web-based mail system that relies on HTTP as its transport [Pac97]. The performance of the tunnel has been adequate for these applications. In addition, the installation and operation of the tunnel have been simple enough that they have not created any new concerns for our firewall administrators.

Our experience indicates that HTTP alone is not sufficient for quality Web-browsing. FTP access is also desirable. A secure FTP proxy, similar to our secure HTTP proxy, would be valuable; together these two proxies would fulfill most browsing needs.

7. Conclusion  

Secure Web tunneling permits controlled access to the Web resources of an Intranet across its firewall. Some of its characteristics are that it does not require software installation on client machines or complicated administration of the Intranet. It provides authenticity and confidentiality properties, while letting the firewall do meaningful access control, logging, and auditing at the HTTP level. For these reasons, secure Web tunneling is a useful addition to a growing set of security techniques and tools for the Web.

References

ABKL93
M. Abadi, M. Burrows, C. Kaufman, and B. Lampson,
Authentication and delegation with smart-cards,
Science of Computer Programming, 21(2): 93–113, October 1993.

Apa
Apache Group,
HTTP server project,
Web pages at http://www.apache.org/.

Atk95
R. Atkinson,
IP Encapsulating Security Payload (ESP),
Web page at ftp://ds.internic.net/rfc/rfc1827.txt, August 1995.

AW97
K.F. Alden and E.P. Wobber,
The AltaVista tunnel: Using the Internet to extend corporate networks,
Digital Technical Journal, 9(2): 5–15, October 1997;
also available on the Web at http://www.digital.com/info/DTJQ01/DTJQ01HM.HTM.

BLFN96
T. Berners-Lee, R. T. Fielding, and H.F. Nielsen,
RFC 1945: Hypertext transfer protocol – HTTP/1.0,
Web page at ftp://ds.internic.net/rfc/rfc1945.txt, May 1996.

CB94
W. Cheswick and S. Bellovin,
Firewalls and Internet Security,
Addison-Wesley, Reading, MA, 1994.

CGHK95
P.-C. Cheng, J.A. Garay, A. Herzberg, and H. Krawczyk,
Design and implementation of modular key management protocol and IP secure tunnel on AIX,
in: Proc. of the 5th USENIX UNIX Security Symposium, June 1995.

FKK96
A.O. Freier, P. Karlton, and P.C. Kocher,
The SSL protocol: Version 3.0,
Web page at http://home.netscape.com/eng/ssl3/ssl-toc.html, March 1996.

KBC97
H. Krawczyk, M. Bellare, and R. Canetti,
RFC 2104: HMAC: Keyed-hashing for message authentication,
Web page at ftp://ds.internic.net/rfc/rfc2104.txt, February 1997.

KM97
D.M. Kristol and L. Montulli,
RFC 2109: HTTP state management mechanism,
Web page at ftp://ds.internic.net/rfc/rfc2109.txt, February 1997.

Nee97
R.M. Needham,
The changing environment for security protocols,
IEEE Network, 11(3): 12–15, May/June 1997.

Pac97
Pachyderm,
Web page at http://www.research.digital.com/SRC/pachyderm/, 1997.