Cipafilter Support:
309 517 2022 option 2
Mon - Fri 7 AM - 6 PM CT
3 - Content Filtering - SSL Configuration
Posted by , Last modified by on 08 July 2013 01:10 PM

Selecting Turn on SSL decryption causes the CIPAFilter to decrypt secured (HTTPS) Web traffic for clients which are being proxied either non-transparently or transparently with Yes+SSL enabled. This enables a number of advanced filtering functions for secured sites; without this enabled, the CIPAFilter can only act on the information which is available in an unencrypted form, which is generally limited to the domain (see note below).

In addition to extending all of the normal HTTP filtering features to HTTPSSSL decryption allows for several HTTPS-specific functions. For instance, SSL decryption is required to make use of the Restrict Google Apps Domain option.

To perform SSL decryption, the CIPAFilter must be able to generate and serve "false" SSL certificates to clients connecting to secured sites. A root certificate authority (CA) is required to sign these certificates; creating this root CA is accomplished by entering the desired information into the SSL Certificate Information section and then clicking the REGENERATE CERTIFICATE button. The specified information will appear in the certificate details for any filtered HTTPS Web site.

Please note that, although SSL decryption will technically function without any further configuration, users will repeatedly be prompted to ignore security alerts in in their browsers (or even be prevented from accessing certain sites entirely) unless they have trusted the CIPAFilter's root CA. Users can download the CA certificate at any time by visiting; it will also be installed automatically (for browsers which respect the operating system's certificate store) by the CIPAFilter authentication client.

A note about the HTTPS protocol:

HTTPS is not a fully separate protocol from HTTP; rather, it is HTTP over a secure connection. In other words, all of the traffic within the secure layer works in the same way as non-secure HTTP traffic. This is an important distinction for a filtering appliance, as it affects what the filter can and can't do with secure connections.

When a client (such as a Web browser) accesses a secure Web site, it creates the secure connection before any actual HTTP traffic is passed back and forth. This is why it is not possible to blacklist entire URLs when SSL decryption is disabled — the URL request occurs inside of the secure connection, so the filter can't see it without intercepting that connection.

Another consequence of this behavior is that the domain name the client establishes the connection with may not be the same as the domain name of the specific Web site it is trying to reach. This is because multiple Web sites may use the same IP address, and the traditional method of distinguishing between different sites on the same address (the HTTP Host header) is, once again, only visible from inside of a secure connection.

To address this problem, a technology called Server Name Indication (SNI) was created, and CIPAFilter uses this to make the black- and white-listing of HTTPS sites more accurate. However, this functionality only works when the client supports it. Notably, older mobile browsers and versions of Internet Explorer running on Windows XP have no SNI support, nor do many non-browser applications (such as Google synchronization tools). Accordingly, blacklist entries may have unexpected results when these clients are involved.

(1 vote(s))
Not helpful

Comments (0)
©Cipafilter 2017. All Rights Reserved.