Secure OWA Architectures, Part 2

In the first article in this two-part series ("Secure OWA Architectures, Part 1," February 2003, http://www.exchangeadmin.com, InstantDoc ID 27484), I described a common Exchange 2000 Server Outlook Web Access (OWA) implementation that provides Internet email access for users who connect to their mailboxes from outside the corporate firewall. The implementation involves OWA installations on the front-end server in the network's demilitarized zone (DMZ); the front-end server relays OWA sessions to the appropriate back-end server in the secure part of the network. Intruders can compromise this implementation because it opens a set of ports on the corporate firewall so that the front-end server can communicate correctly with the back-end server. In Part 2, I look at more secure approaches that facilitate OWA access to mail services for users who are located outside the corporate firewall and provide an architectural perspective and specific implementation information.

OWA Access Problems
Placing front-end servers in the network's DMZ requires that you open various ports on the internal-facing firewall—typically, as many as 11 (Part 1 contains a list of requisite open ports). Obviously, the more open ports on the firewall, the more opportunities intruders have to gain unauthorized access to your network. Reducing the number of firewall openings and minimizing or eliminating unauthorized access is the objective of any security "hardening" activity.

Although you can use a Secure Sockets Layer (SSL)/Transport Layer Security (TLS) connection to secure communications between the OWA client and the front-end server, you can't encrypt communications between OWA front-end and back-end servers. Therefore, if your DMZ is compromised, HTTP-DAV communications between the front-end and back-end servers will be exposed. (Although you can use basic HTTP connections to maintain and establish OWA communications, administrators rarely do so because of the resulting security risk, especially the risk of passing passwords in plain text.) Likewise, you can use an IP Security (IPSec) channel between the front-end and back-end servers to secure interserver traffic, but if intruders compromise the IPSec connection, they'll have an easy path through your internal firewall.

An Architecture Solution
The most effective approach to securing an OWA environment uses a proxy server in the network's DMZ. The proxy server receives client requests from the external browser client and forwards those requests to the front-end server. Think of the proxy server as an architectural component; later, we'll look at its software and hardware implementations.

The proxy-based solution enhances architecture security because it serves two primary purposes. First, it lets the front-end server reside securely on the internal part of the network without necessitating any openings on the internal firewall. Second, this solution facilitates a secure SSL/TLS connection from the browser client to the front-end server. The proxy server allows connections to the front-end server in two ways—through an SSL/TLS tunnel or an SSL/TLS bridge, both of which Figure 1 shows. Typically, you'll use only one method.

Tunneling and Bridging
In the SSL/TLS tunneling approach, the proxy server receives HTTP packets from the browser client and forwards those packets to the front-end server. The proxy server is cryptographically passive and doesn't process communications between the browser client and the front-end server; rather, it acts as a conduit to relay packets and provide complete end-to-end security. SSL/TLS tunneling is a common approach for both hardware and software implementations and is particularly relevant for small-scale environments because the SSL/TLS processing load remains with the front-end server. In general (depending on the nature of the communications stream), adding an SSL/TLS cryptographic-processing workload to a Web server (in this case, an OWA front-end server) results in a CPU-processing overhead of at least 15 percent. Use the tunneling model to support small numbers (a few hundred) of OWA users (even without crypto-acceleration cards). We'll discuss crypto-accelerator cards in more detail later; these cards perform specialized cryptograhic-processing tasks, thus offloading the effort from the CPU.

You can also use the proxy server to provide SSL/TLS bridging functionality as an alternative to tunneling. As Figure 1 shows, in SSL/TLS bridging, the proxy server is analytically active and terminates the SSL/TLS connection from the browser client at the proxy server. The proxy server then establishes a new connection to the front-end server, usually through SSL/TLS, but you can also use a basic HTTP connection. Using an SSL/TLS bridge is often desirable because it offloads the computationally intensive task of SSL/TLS cryptographic processing from the front-end server, which lets you support large numbers of Web browser clients (typically several thousand clients). From a security perspective, terminating an SSL/TLS session at the proxy server, inspecting the packets, and forwarding only legitimate sessions to an application server in the secure part of the network is the best approach.

Putting the Processes into Practice
Using a proxy server to offload the SSL/TLS processing overhead from the front-end server can be taxing to the system. Even as few as 50 SSL/TLS connections per second can saturate the average system (i.e., a 900MHz Pentium III system). For software-based proxy-server implementations, you can use dedicated SSL/TLS PCI crypto-accelerator cards to offload cryptographic processing. In Microsoft-centric environments, a software-based proxy server usually consists of a Windows 2000 server running software such as Microsoft Internet Security and Acceleration (ISA) Server 2000 or the Symantec Enterprise Firewall, coupled with an SSL/TLS crypto-accelerator card. These cards can process approximately 500 SSL/TLS connections per second. Many manufacturers' acceleration cards, such as Rainbow Technologies' CryptoSwift Hardware Security Module (HSM) and Atalla's AXL600L SSL Accelerator Card, cost about $2500.

The alternative to a software-based proxy server is a dedicated network appliance that's similar to a network switch but is dedicated to cryptographic processing. These dedicated appliances don't run any conventional OSs as such. Hardware-based proxy servers provide high performance and can support larger numbers of simultaneous sessions and higher rates of cryptographic-processing throughput compared with their software-based counterparts. For example, Nortel Networks' Alteon 410 SSL Accelerator can process 2000 SSL/TLS connections per second and sustain as many as 16,000 simultaneous SSL/TLS sessions. Similar SSL/TLS accelerator devices are available from Cisco Systems, F5 Networks, and Radware. Increased performance can be expensive, however, and prices for hardware-based proxy-server appliances range from about $15,000 to $50,000, depending on performance and functionality.

Using ISA Server with OWA
You can use ISA Server 2000 as a software-based proxy server in SSL/TLS tunneling and bridging modes. Run ISA Server 2000 Service Pack 1 (SP1—build 3.0.1200.166) or later (you can download SP1 from http://www.microsoft.com/isaserver/downloads/sp1.asp).

To implement SSL/TLS tunneling (the least common architectural implementation), use ISA Server 2000's Server Publishing feature. To set up bridging—the most common architectural implementation—use the Web Publishing feature. The Microsoft article "How to Publish Outlook Web Access Behind Internet Security and Acceleration Server" (http://support.microsoft.com/?kbid=290113) provides detailed implementation steps; a simplified version follows. Perform all operations from the ISA Server Management Console.

The process for configuring ISA Server 2000 to act as a proxy server is straightforward. Now let's look at configurations that use hardware-based proxy-server implementations.

Using a Hardware-Based Proxy Server with OWA
Hardware-based proxy servers deliver the best performance. Don't think of these appliances as direct replacements for ISA Server 2000 (because ISA Server 2000 also performs important firewall duties) but as alternative workhorses for SSL/TLS processing. In many cases, cryptographic processing is performed solely on the network appliance; a first proxy phase takes place on the ISA Server 2000 server, and further phases take place on the network appliance.

In this article, I describe topology options that use Radware's CertainT 100 SSL accelerator. But, in general, you can employ broad topological frameworks with any hardware-based proxy-server device.

In its simplest configuration, you can use the SSL/TLS accelerator in an "in-line" topology, in which all traffic is routed through the device. As Figure 4 shows, inbound connections from browser OWA clients use a URL to access mailboxes (https://webmail.cantaz.com). The ISA Server 2000 server sends the HTTP requests to the hardware proxy server, at which the SSL/TLS processing takes place before the proxy server forwards the HTTP packets to the OWA front-end server (using either basic HTTP or HTTP Secure—HTTPS).

This straightforward topology has a few drawbacks. First, when you use in-line mode, all traffic—not just HTTPS traffic—must pass through the proxy server, so this method is less than ideal from an architectural perspective and not desirable when user loads are high. The in-line mode processes only HTTPS traffic; other traffic is effectively bridged from the input network interface to the output network interface. Second, in most cases, the proxy server must reside on the same subnet as the HTTPS stream's source and destination (i.e., on the internal part of the network). You could implement yet another ISA Server 2000 server­style proxy device between the proxy server and the OWA front-end server to provide some form of address translation, as Figure 5 shows, but in the former scenario, the SSL/TLS accelerator proxy server is firmly resident in the DMZ.

Configuring the CertainT 100 to operate in this mode is straightforward. Use a serial cable to connect to the device, then issue the commands to associate an IP address with the system and place it in in-line or bridging mode, as Figure 6 shows.

After you associate an IP address with the device, you can use the HTTP-based management interface to connect to the device. (Some vendors' devices ship with a default address that you use a browser to connect to so that you don't need a serial connection.) An alternative architectural approach uses the proxy server in an SSL/TLS accelerator server-farm topology, as Figure 7, page 10, shows.

In server-farm mode, the ISA Server 2000 server makes a destination routing decision based on the type of traffic it processes. As Figure 7 shows, only SSL/TLS traffic is routed to the proxy-server SSL accelerator; all other traffic is routed to its intended destination without reference to the proxy server. This operation mode is more scalable than the in-line mode; rather than use just one proxy server, you can configure a bank of proxy servers and use a load-balancing switch (with support for session affinity) to distribute SSL connections across the servers. You need session-affinity support because the load-balancing devices must always route packets to the same proxy server for the duration of a particular session.

Back-End Encryption
Both software- and hardware-based proxy servers provide back-end encryption. That is, although the proxy server is responsible for the heavy cryptographic processing of many hundreds or thousands of simultaneous connection requests, it can still maintain a secure SSL/TLS connection to the front-end server. But why isn't the cryptographic load on the front-end server as high as the load on the proxy server? The proxy server must manage and perform the handshaking for many thousands of key pairs for each connecting client—an n-to-1 relationship that represents the bulk of the cryptographic processing load. A key pair represents the collection of public keys and private keys that the client and proxy server use for the secure connection. But the partnership between the proxy server and the front-end server is a one-to-one relationship. As a result, managing key pairs and the associated handshaking is considerably simpler, with lower encryption strength—often 56-bit key lengths between the proxy server and the front-end server compared to 128-bit key lengths between browser clients and the proxy server.

You can take many different approaches to providing secure access to OWA mail services, and each approach has its merits. Some approaches are simple to implement, some are highly scalable, and some are expensive, but all provide some degree of protection. You might not have the budget to implement the Rolls-Royce solution, but some protection is better than none.