A: I was asked this question by someone who was considering changing the publishing rules defined on an Internet-facing ISA 2006 firewall for securing access to an Exchange 2007 messaging infrastructure. The goal was to offload the ISA Server by using a server publishing rule instead of a web publishing rule for Outlook users that access the backend Exchange 2007 Client Access Server (CAS) server farm from a trusted corporate network.
The users connected to the Exchange infrastructure from behind a corporate Internet proxy, not directly connecting from the Internet. The thought was that, security-wise, it makes sense to not perform HTTP-level inspection on the ISA server, but simple packet filtering as offered by an ISA server publishing rule. HTTP-level inspection can be configured when you use an ISA web publishing rule.
All Outlook users connected to the infrastructure using HTTP over SSL (HTTPs). So the question is, when using SSL and a server publishing rule, could they still terminate the incoming Outlook SSL sessions on ISA Servers?
The idea of using a web publishing rule instead of a server publishing rule to offload the ISA Server makes sense. When using a server publishing rule, ISA acts as a packet filter. (When using a web publishing rule, ISA acts as an application proxy.) Application proxies operate on the highest level of the TCP/IP network reference model, can inspect application-level protocols such as HTTP, and typically require more processor resources than server publishing rules. A server publishing rule operates on the transport (TCP) level of the TCP/IP network reference model and only performs packet filtering based on the originating IP address and port number.
These properties explain why an ISA server publishing rule can't be used for terminating Secure Sockets Layer (SSL) sessions on an ISA Server. SSL is a protocol that operates between the transport (TCP) and application levels of the TCP network reference model. A server publishing rule can forward higher-level protocols such as SSL, but doesn't have the intelligence to terminate those protocols and translate them into, for example, a plain HTTP session to the backend infrastructure. In other words, a server publishing rule only supports SSL bridging and not SSL tunneling. For the sake of completeness, I've included a short explanation on the differences between SSL bridging and tunneling below.
When you want to use an ISA server publishing rule for publishing your Exchange CAS servers, you need to look at another layer to terminate your SSL sessions. You could do so either on the CAS layer or on some networking device that sits in between the CAS and ISA server, such as a load balancer or a specifically designed SSL offloading device (typically a hardware appliance).
SSL Tunneling Versus SSL Bridging
SSL tunneling means that the SSL-protected traffic is tunneled through the firewall. When data is tunneled, it's encrypted, so a firewall can't inspect it. SSL tunneling typically provides end-to-end SSL—the SSL tunnel starts on the browser (the SSL client) and ends on a web server (the SSL server). It requires an SSL authentication certificate on the web server and, optionally, an SSL client certificate on the client side.
The alternative to SSL tunneling is SSL bridging. In an SSL bridging setup, the SSL tunnel is started or terminated on the level of the firewall. This also means that the firewall can inspect the content of the SSL tunnel. The tunneled data is available on the firewall just before it's encrypted or just after it's decrypted.
With SSL bridging, there’s no end-to-end SSL tunnel setup. SSL bridging can be set up in several ways:
- Option 1: Use a single SSL tunnel that starts on the client side and terminates on the firewall. This method requires an SSL certificate for the firewall and, optionally, an SSL certificate for the client side if strong client-side authentication is required.
- Option 2: Use a single SSL tunnel that starts on the firewall and terminates on the web server. This method requires an SSL certificate for the web server and, optionally, an SSL certificate for the firewall.
- Option 3: Use two SSL tunnels, one starting on the client and terminating on the firewall and the other starting on the firewall and terminating on the web server. This method requires SSL certificates on the firewall and web server and, optionally, on the client side.
