Proxy configurations: The lesser of two evils

As we tested the IronPort S-Series, we quickly ran into an old and unsolved problem with enterprise Web proxies: how to get end user browsers to actually use the proxy.

When a Web browser uses a proxy, the protocol between the browser and the Web proxy is slightly different from the one a browser uses straight to a Web . Thus, the best interoperability between Web browser and Internet Web servers occurs when the browser is aware of the proxy.

If the proxy server is inserted transparently between the client and the server, without any special browser configuration, then several problems quickly creep up. Some of the problems are show-stoppers. For example, if the proxy attempts to decrypt SSL traffic, the browser will raise alerts. If the proxy requires authentication to differentiate different types of users or for accounting, this can be incompatible with other Web pages that also require authentication. There's a whole RFC (RFC-3143) listing problems with Web proxies.

On the other hand, if you want perfect interoperability, you have to get the proxy configuration information to the Web browser somehow. Several semi-automatic methods exist under the rubric of Web Proxy Auto-Discovery Protocol (WPAD), or, you could manually load the proxy configuration information into the PC.

These two options set up the tension that network managers have to deal with: transparent proxy (also called "intercepting proxy") which doesn't require touching the Web browser, but also doesn't work all the time, vs. explicit proxy that requires WPAD and a cooperating device, but which works much better.