By default, the SSL proxy only intercepts HTTPS traffic when there is an exception—such as a certificate error—and tunnels all other HTTPS traffic. However, if you want to apply other security measures such as virus scanning or content filtering to SSL traffic you must configure the appliance to intercept SSL traffic. Keep in mind that the encryption and decryption operations required for SSL intercept are resource intensive; therefore you should only intercept the SSL traffic that you believe poses a threat to your network. You specify what SSL traffic to intercept by creating policy rules in the SSL Intercept layer.

One way to define which SSL traffic to intercept is to restrict intercept based on user or group membership as follows:

1. Make sure you have an SSL license. 

Although some appliance models include an SSL license, other models require that you purchase and install an add-on license. To see whether you have a valid SSL license, launch the Management Console and select Maintenance > Licensing > View. You should see an entry for SSL in the list of licensed components.



2. Set up the issuer keyring and CA certificate list (CCL) to allow the ProxySG appliance to emulate server certificates. 

When the ProxySG appliance intercepts HTTPS traffic, it establishes two separate SSL connections: one between the client and the appliance and one between the appliance and the OCS. In order to establish the SSL connection with the client and to enable it to decrypt the data, the appliance emulates the OCS certificate, making itself (the ProxySG appliance) the certificate issuer. To enable this behavior you must:

a. Determine which keyring to use to emulate OCS certificates. You can: 

• Use any of the built-in keyrings that include both a certificate and a key pair (such as default). 
• Create a new keyring and generate a self-signed certificate. 
• Use a local CA (such as Microsoft Certificate Services) to act as your Root CA and use it to generate a subordinate CA certificate for the ProxySG appliance. 

b. Designate the keyring you have chosen as the Issuer Keyring within the SSL proxy configuration (Configuration > Proxy Settings > SSL Proxy).
 
c. (Optional) If the issuer keyring contains a certificate generated by a CA that the client browsers do not trust (such as a self-signed certificate), you must download the  ProxySG certificate as a CA certificate to client browsers to prevent the browsers from displaying a pop-up warning to the users when they browse to an HTTPS site. To simplify this process, email the URL that corresponds to the issuer certificate to your end users (Statistics > Advanced > SSL > Download a ProxySG Certificate as a CA certificate).
 
3. Create the authentication realm for authenticating the users/groups you will be using to enforce your SSL intercept policy.  
 
4. Set up the proxy services as necessary to intercept HTTPS traffic. 

The way you do this depends on your deployment type:

• Explicit proxy—Configure the Explicit HTTP Proxy service or the SOCKS Proxy service to intercept all explicit traffic (usually on ports 80 and 8080 for HTTP or port 1080 for SOCKS) and enable the Detect Protocol attribute. This allows the HTTP or SOCKS proxy to detect HTTPS traffic and hand it off to the SSL Proxy.

Transparent proxy—Edit the HTTPS service to use the TCP Tunnel Proxy to intercept traffic on port 443. You must also enable the Detect Protocol attribute. This allows the TCP tunnel proxy to detect HTTPS traffic and hand it off to the SSL Proxy.



NOTE: In this specific deployment where you want to make SSL intercept decisions based on user or group, you must use the TCP Tunnel proxy rather than the SSL proxy because the SSL proxy does not authenticate until after it has determined whether to intercept traffic. You can use SSL proxy when making intercept decisions that do not require access to user or group information. However, in this case you would also need to edit each proxy service to define which HTTPS traffic should be intercepted by each.
 
5. Create a Web Authentication layer to enable authentication using the realm you created:

a. Launch the Visual Policy Manager (VPM) by selecting Configuration > Policy > Visual Policy Manager > Launch. 
b. Select Policy > Add Web Authentication Layer. 
c. Create the rule to enable authentication using the authentication realm you created in Step 3. Keep in mind that for transparent proxy, when you configure the Authenticate object in the Action field, you must select an authentication Mode that uses an IP surrogate (Origin IP Redirect or Form IP Redirect for transparent proxy or Proxy IP for explicit proxy).



NOTE: The SSL proxy can only make a decision to intercept HTTPS traffic based on user if it can associate the IP address in a client request with a username. However, because it does not support transparent authentication, it can only do this if the appliance has an existing IP surrogate credential for the client. This means that unless the client has recently authenticated using a protocol that supports transparent authentication, such as HTTP, the appliance will not be able to make SSL intercept decisions based on user.
 
6. Create an SSL Intercept layer:

a. In the first rule, set the Source to the user or group you want to use to determine whether to intercept SSL traffic. For example, if you want all traffic from users in the Finance group to bypass SSL intercept, you would select the Group object and set the value to Finance.
b. Specify how to handle traffic that matches the conditions you set in the Source field by selecting Action. For example, to bypass SSL interception for the users in the Finance group, you would select Disable SSL Interception.
c. Create any additional user- and/or group-based rules by setting the Source and Action as specified in steps a and b. For example, you might create a second rule that disables SSL intercept for the CEO. In this case, you would set the select a User object in the source field and specify the CEO's username and Disable SSL Interception as the Action.
d. Create a final rule that specifies what to do with remaining SSL traffic that does not match any of the rules you defined. For example, to intercept any SSL traffic that does not match the previous rules, create a rule that sets the Action to Enable HTTPS Interception and leaves the other fields set to the default values. In this example, this would mean that SSL traffic from users in the finance department or from the CEO will not be intercepted but all other SSL traffic will be intercepted.



7. (Explicit proxy only) Set up each client Web browser to use the ProxySG appliance as its proxy server. 

Typically, the browser proxy configuration requires the IP address or hostname of the ProxySG appliance and the port on which the ProxySG appliance will listen for traffic. The default port is 8080. The required hostname format (that is, whether you must provide a fully qualified DNS hostname or a short hostname) depends on the DNS configuration on the client systems.
 
8. Verify your SSL intercept policy. 

To do this, browse to a secure site—such as https://www.facebook.com—and check to see that the traffic was intercepted (or not intercepted) as expected based on your policy. There are two ways you can do this:

• From the client browser— Check to see that the certificate used for the SSL session is the certificate issued to the ProxySG appliance rather than the certificate issued to the OCS. For example, if you are using the ProxySG Default keyring for SSL traffic, the organization name of the certificate will have a ProxySG: prefix.  
• From the appliance—If you have access logging enabled, you can look in the SSL access log the for the corresponding HTTPS requests in the logs.