More and more organizations are adopting Microsoft Internet Security and Acceleration (ISA) Server 2000 as a proxy and firewall solution for their IT infrastructure. ISA Server is the follow-up product to Microsoft Proxy Server 2.0, but unlike its predecessor, which was primarily a Web caching solution, ISA Server can serve as a full-blown firewall. In addition, ISA Server provides advanced packet filtering and application-proxy firewall functions. The firewall also uses a stateful engine, which secures Secure Network Address Translation (SNAT). For a complete overview of ISA Server's features, visit the Microsoft ISA Server Web site at http://www.microsoft.com/isaserver, visit the ISAserver.org Web site at http://www.isaserver.org, or see "Related Reading," page 2.
Organizations can use ISA Server as a proxy, a firewall, or both. In this combined role, ISA Server protects your Web servers from the dangers of a public network such as the Internet and provides Web content caching for Web users (i.e., proxying) and Web servers (i.e., reverse proxying). Whereas vendors such as Cisco Systems and Nokia provide dedicated hardware-based firewall and proxy solutions equipped with HTTP proxy software, ISA Server is simply a software-based solution.
Let's look at how to set up the Secure Sockets Layer (SSL)/Transport Layer Security (TLS) protocols for secure Web connections. Specifically, I review which SSL scenarios you can use with HTTP proxies, how to request and obtain SSL certificates, and how to configure ISA Server for SSL bridging and tunneling. I also mention a key factor when securing ISA Server: the SSL processing load.
The ISA Server installation I describe in this article uses ISA Server Service Pack 1 (SP1), which requires Windows 2000 SP2, and ISA Server Feature Pack 1. Microsoft released the feature pack earlier this year, and you can download it at http://www.microsoft.com/isaserver/featurepack1/default.asp.
Securing an OWA Environment
Figure 1, page 2, shows a typical Microsoft Exchange 2000 Server Outlook Web Access (OWA) setup. OWA lets Exchange users access their mailbox data from an Internet browser. In this environment, ISA Server combines a firewall with a proxy solution and functions as an advanced software-based HTTP proxy server. Instead of communicating directly with the OWA front-end Web server, Web clients connect through the HTTP proxy server, which greatly enhances the overall security of the OWA infrastructure. ISA Server also caches and analyzes the OWA Web content.
From a perimeter security point-of-view, the OWA users are on an untrusted network (e.g., the Internet) and the OWA front-end Web server and Exchange server are in a trusted network zone (e.g., an internal corporate network). ISA Server separates the untrusted security zone from the trusted security zone. Although you can take several other steps (including adding a demilitarized zone—DMZ) to securely deploy ISA Server, these permutations are beyond the scope of this article.
The Crucial Role of SSL/TLS
Web sites that handle confidential information (e.g., credit card numbers) often use SSL to secure Web traffic. SSL is a security protocol operating at the transport layer of the Open System Interconnection (OSI) networking stack. SSL provides authentication, confidentiality, and integrity protection to application-level protocols (e.g., HTTP, SMTP). Netscape developed SSL, and you can download the most recent SSL specification (SSL 3.0) at http://wp.netscape.com/eng/ssl3. In 1999, Internet Engineering Task Force (IETF) Request for Comments (RFC) 2246 standardized SSL under the name Transport Layer Security (TLS) protocol (more information is available at http://www.ietf.org/rfc/rfc2246.txt). TLS is also known as SSL 3.1. In the discussion that follows, the term SSL refers to both the SSL and TLS protocols. Eric Rescorla's SSL and TLS: Designing and Building Secure Systems (Addison-Wesley, 2001) reveals all the nuts and bolts of both protocols.
SSL and HTTP Proxies
When working with HTTP proxies, you can configure SSL in one of two ways: SSL tunneling or SSL bridging. Web Table 1 (http://www.secadministrator.com, InstantDoc ID 38099) shows the different SSL approaches and their advantages and disadvantages.
SSL tunneling provides true end-to-end SSL protection, as Figure 2 shows. The SSL tunnel starts on the browser and ends on the Web server. SSL tunneling requires an SSL authentication certificate on the Web server; an SSL client certificate on the client is optional. The primary disadvantage of using SSL tunneling is that it breaks the security role of an HTTP proxy, which typically inspects HTTP request content before letting the request through to the Web server. When you use SSL, the HTTP proxy can't inspect the HTTP request because the SSL tunnel encrypts the HTTP content. Because SSL operates on the transport level of the OSI networking stack and HTTP operates on the application level, the SSL tunnel is always in place before the HTTP application-level traffic reaches the destination host.
To configure SSL tunnels to flow through HTTP proxies, SSL-enabled applications use the HTTP CONNECT method. This method tells the HTTP proxy to ignore the content of an SSL session and to simply forward the SSL packets to the destination host (in our example, an OWA front-end Web server). RFC 2817 defines the HTTP CONNECT method.
SSL bridging, unlike SSL tunneling, lets you add a secure pathway without removing the HTTP proxy security because the SSL tunnel starts or terminates on the HTTP proxy. You can set up SSL bridging in one of three ways:
- SSL bridging option 1—one SSL tunnel that starts on the client side and terminates on the HTTP proxy, as Figure 3 shows. This option requires an SSL certificate for the HTTP proxy; you can also use an SSL certificate for the client when strong client-side authentication is necessary.
- SSL bridging option 2—one SSL tunnel that starts on the HTTP proxy and terminates on the Web server, as Figure 4 shows. This option requires an SSL certificate for the Web server; you can also use an SSL certificate for the HTTP proxy when strong client-side authentication is necessary.
- SSL bridging option 3—one SSL tunnel that starts on the client and terminates on the HTTP proxy and another that starts on the HTTP proxy and terminates on the Web server, as Figure 5 shows. This option requires an SSL certificate for the HTTP proxy and an SSL certificate for the Web server; you can also use an SSL certificate for the client when strong client-side authentication is necessary.
Prev. page
[1]
2
3
next page 
