 |
Martín Abadi -
Andrew Birrell -
Raymie Stata -
Edward Wobber
Systems Research Center,
Digital Equipment Corporation,
130 Lytton Avenue, Palo Alto, CA 94301, USA.
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.
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.
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.
Although these protocols often perform some form of user authentication, data typically passes unencrypted over insecure phone lines and sometimes over the network of an Internet Service Provider (ISP). Moreover, there is almost no logging or auditing of transactions. Finally, dialup connections require access to modems and to phone lines, so they are usually not viable from a public terminal.
Unfortunately, this approach allows all IP packets from trusted users to pass into the Intranet, while only HTTP access is required. Because this approach works at the IP routing level, it is impractical to log or audit all transactions across the firewall, so security breaches are difficult to detect. Thus, the integrity of the entire Intranet may depend, for example, on low-level configuration options in the portable computers or the home computers of trusted users; neither these computers nor their configuration options are generally well protected. For these reasons, firewall administrators often have reservations about IP tunnels. In addition, IP tunneling is not viable from public terminals, because it would require software installation.
This approach is not a practical solution in many Intranet environments. In particular, it is often difficult for the firewall administrator to determine and maintain the list of hosts that should be accessible from the outside. Furthermore, each host that can receive direct connections from the outside effectively becomes part of the security perimeter of the Intranet. Adding many such hosts seems inimical to security, and in any case contradicts the purpose of firewalls.
The reverse proxy approach is unsatisfactory for our purposes in several respects. First, the URLs used from the outside differ from those used inside the firewall: the former bear the name of the proxy server rather than that of the content server. So, for example, a URL that was saved as a bookmark inside the firewall may not work from the outside. Similarly, a URL contained in a page retrieved across the firewall may not work from the outside. Furthermore, this approach requires explicit configuration in the external proxy server for each Intranet Web server to be accessed. In conclusion, this approach does not seem viable for a large or rapidly evolving Intranet.
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.
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.
As shown in Figure 1, the Web tunnel has three main components, the authenticator, the redirector, and the proxy:
Tom's browser tries to access http://hr.acme.com/foo.htm by sending a non-secure HTTP request to the redirector. If the redirector accepts this request, it responds using the HTTP redirect facility: it tells the browser to reissue the request using a new URL, which is given as part of the redirect response. This new URL is an HTTPS URL, and causes the browser to connect to the proxy component of the Web tunnel. Section 3.3 describes this new URL in more detail.
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.
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.
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.
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.
In more detail, when a principal accesses internal Web services through the tunnel, the following security properties hold.
If an attacker tampers with the initial HTTP redirect, then the principal may connect to a fake tunnel. If the principal mistakenly provides authentication material to a fake tunnel, then the fake tunnel can gain access to the Intranet. It is therefore important that the principal check the identity of the tunnel that has been authenticated. Although JavaScript code may rewrite the location field that the principal sees, common browsers can provide the identity of the tunnel reliably (by displaying its X.509 certificate), so the principal can perform the necessary check.
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.