Understand Client Context

HTTPS URL Blocked

If the client makes an HTTPS request for a site the Web Gateway’s policy determines should be blocked, the Web Gateway will issue a block page.  In order for that block page to be presented to the client (remember that the client expects a proper SSL handshake when it makes an HTTPS request), the Web Gateway must interact with that SSL Connection to be able to present the block page inside an SSL tunnel.

To do so, the Web Gateway issues a web server certificate (with common name matching the request from the browser, and signed by a certificate authority loaded on the box). It uses this web server certificate to establish the SSL connection with the client, in order to present the block page.

Note the ‘Issuer’ of the certificate.  This is a Certificate Authority that is configured on the Web Gateway appliance:

In the event that the Web Gateway policies determine a request should be blocked, the Web Gateway will never establish a connection to the external web server.  Take a look at the SSL handshake that occurs in this case:

As noted above, the Web Gateway never makes a connection to the external host.  We can see this behavior in the below packet trace (taken on the Web Gateway, viewed within Wireshark):

INFORMATION FOR WIRESHARK IMAGE BELOW: Client IP: 10.10.89.1 – Web Gateway IP: 10.10.89.117

Connection error when browsing to HTTPS site

In the event of an upstream connection error (which could be a DNS failure, upstream tcp connection failure, etc.), the Web Gateway will also attempt to display a block page.  Just as in the example for URL blocked, the Web Gateway must interact with that SSL connection between the client and itself. 

Web Gateway Redirection

Redirection as an action is more common in transparent deployments, but not exclusive to them.  A common example is if the client browser needs to be redirected to the authentication server.  In order to provide that redirection to the client, we need to issue an HTTP ‘302 – redirect’ response.  That response must be inside of the SSL tunnel.  Thus, we must interact with that SSL connection to issue the response.

Certificate Authorities - some background

A Web server certificate is a certificate provided to a client, by a specific, distinct, web host, for the purpose of establishing an SSL tunnel.  That certificate is ‘signed’ by a Certificate Authority.

The web server certificate is for a specific host (i.e. skyhighsecurity.com).  This web server certificate cannot be used for another host (i.e. supersecureportal.sitename.com).

Remember the client browser requirements above state that the certificate’s common name must match the name typed in the browser’s address bar.  Since the Web Gateway must be able to dynamically create a web server certificate on the fly, for possibly any requested URL host, a ‘Certificate Authority’ must be configured on the appliance.

You will NOT be able to configure a ‘public’ Certificate Authority (Verisgn, Thawte, EnTrust, etc.) on the appliance, since you will not be able to obtain a ‘Certificate Authority’ from those public CAs and use it for our purposes.  It is the ability to ‘dynamically’ sign web server certificates that is not available to most organizations by the publically trusted authorities.  (Those authorities will sign and provide ‘a’ specific web server certificate, but not a CA certificate that allows signing of other certs) You will NOT be able to purchase a Certificate Authority from a public authority!!

Configuring a Certificate Authority on Web Gateway

You have two options to configure a Certificate Authority on the appliance:

First, you can generate a Certificate Authority directly within the user interface.  Within the Web Gateway product guide, navigate to ‘Chapter 10 > Web Filtering > SSL Scanning > Replace the default root certificate authority > Create a root certificate Authority’.  Once this CA is generated, you can export that cert and push it out to your client workstations so they can trust it.

Second, you can import a local certificate authority onto the appliance.  Many organizations use a local certificate authority (such as Microsoft’s CA) to sign their internal certs, and usually these are already trusted by domain workstations. Within the Web Gateway product guide, navigate to ‘Chapter 10 > Web Filtering > SSL Scanning > Replace the default root certificate authority > Import a root certificate Authority’.  

Background on SSL Client Context with CA Event

As mentioned above, if the Web Gateway must ‘interact’ with an SSL connection (i.e. if you would like to send any HTTPS traffic through the Web Gateway), the Web Gateway must have the ability to issue a web server certificate to the client, dynamically created and signed by the Certificate Authority configured on the appliance (see above).

This functionality is provided by the ‘Event’ called “Enable SSL Client Context with CA”:

You can see that the event “Enable SSL Client Context with CA” references a setting container (in this case, the ‘Default CA’ container).  This setting container references a certificate authority that must be configured on the Web Gateway appliance.

Tip: You can have multiple Certificate Authorities installed, in separate setting containers:

How to use the SSL Client Context with CA event

If you are NOT using the SSL Scanner rule set, then the event “Enable SSL Client Context with CA” should be placed in a rule, within the top-most rule set of your policy:

Here’s how to create it:

First, click to ‘Add’ a new Top Level Rule Set, and create one that looks like below:

Next, after placing the new rule set ‘Enable SSL Client Context for deployments without SSL Scanning’ as the top most rule set, create a rule within that rule set like below:

Finally, when selecting the “Setting” container, be sure you select the container you used when configuring the Certificate Authority on the appliance, as in the prior instructions above.