How It Works

There are two possible ways to deploy Squid proxy and Web Safety ICAP server to filter HTTPS traffic and perform HTTPS decryption. Each way has its advantages and disadvantages.

Way 1: Explicit Proxying (Recommended)

In this case a browser is explicitly directed to use the proxy that is deployed in the same network for both HTTP and HTTPS protocols. When this type of deployment is used traffic flow looks like the following:

* When a user wants to navigate to unencrypted web site, browser sends the request to proxy server, asking it to get the requested page on his behalf using HTTP protocol. Proxy establishes a new connection to the remote site, gets the server response, filters it and returns it to the browser.

* If user navigates to the encrypted web site, then the browser asks the proxy to establish a virtual tunnel between itself and remote server and then sends encrypted data to the server. Domain name to which a virtual tunnel is being established is usually known, so proxy is able to block this virtual tunnel when it finds out that domain name belongs for example to a prohibited category. The proxy is also able to decrypt the request from the browser, send it to the remote server, filter it, encrypt it again and pass it back to the browser. As browser trusts the proxy it continues working with filtered HTTPS without any errors or warnings.

The following describes advantages and disadvantages of explicit proxying.

Advantages * Filtering exceptions are easily done by domain name and can usually be easily managed from the Web UI. * It is easy to exclude some applications/programmatic components (like Java) from going to the proxy (using PAC files for example). * Proxy authentication is fully supported (including single-sign-on scenarios like Microsoft Active Directory). * If something goes wrong it is easy to troubleshoot traffic flow on the proxy. * It is relatively easy to build proxy redundancy and proxy farms. * If you have all your workstations joined to Microsoft Active Directory, deployment of a self-signed Root CA certificate for HTTPS inspection may not be required. You can use the subordinate CA issued by Active Directory Certificate Services.

Disadvantages * Browser must trust the root certificate of the proxy that is used to decrypt and re-encrypt HTTPS / SSL traffic. * Browser must be configured to use the proxy explicitly. This can be easily done in a managed network using GPO in Microsoft Active Directory or automatic proxy configuration script (PAC file).

Way 2: Non-Explicit (Intercept) Proxying

In this case the browser is not aware of proxy existence and does direct communications with remote web servers. Special firewall rules on gateway redirect HTTP and HTTPS traffic flow to the Squid instance running on gateway and allows filtering it.

The following describes advantages and disadvantages of non explicit proxying.

Advantages * Browser does not need to be configured to use the proxy.

Disadvantages * Browser must trust the root certificate of the proxy that is used to decrypt and re-encrypt HTTPS / SSL traffic (same as in explicit proxy scenario). * Filtering exceptions need to be managed on the firewall device using rule manipulation commands. It is hard to keep up with the regular changes of the IP addresses of domain names. * Exclusion of applications needs to be done on the firewall level manually. * Proxy authentication is not supported. * If something goes wrong traffic flow needs to be analyzed on the firewall potentially affecting a lot of applications. * It is hard to build gateway redundancy.

Recommendation

Comparing advantages and disadvantages of two styles of deployment we do recommend using the explicit proxy approach. Our :doc:../virtual_appliance/index contains everything necessary to be used as explicit proxy out of the box.