HTTPS Filter and SSL Inspection has been available from Version 6.2.0 and the following gives a brief overview.
The HTTPS protocol was designed to provide secure means of communications between internet browsers and remote web servers. In order to achieve this, HTTPS uses SSL to encrypt data passing through connections from browser to remote server (and back) so that it cannot be easily decrypted in a short amount of time by others – hopefully preventing anyone making illicit use of exchanged data. This protocol was primarily invented to enable safe and secure communication between the user and financial sites over the insecure medium such as the Internet.
More and more web sites including social media and search engines, use HTTPS encrypted communications to increase online privacy of users. Google in particular lead this this trend. Undoubtedly, HTTPS encryption is a good thing for some elements of security , but for those in education and commerce sectors tasked with implementing both e-safety and ensuring users abide by Acceptable Use Policies it has posed a significant problem, as traditional monitoring and filtering mechanisms implemented by organisations have not been able to check encrypted transmissions. Further, such encrypted transmissions may carry viruses, and unless organisations can undertake the necessary checks and block malware (as it would with plain HTTP), then undoubtedly there are some big issues.
NIS have implemented two mechanisms to assist.
NetPilot and SoHoBlue HTTPS Filtering and SSL Inspection Implementation
It’s important to note that the NetPilot/SoHoBlue implementation has two levels functionality described below and are available in V6.2.0+ software.
- HTTPS URL Filtering
The URL level filtering is incredibly easy to deploy, requires no client configuration and is the new default mode on all our products.
If you only need to Block/Allow by URL categories, you can enable HTTPS URL Filtering. Unlike SSL Inspection, HTTPS Filtering does not decrypt the encrypted portion of the transmission but knows how to check the other elements of HTTPS packets.
Encrypted user data is not monitored for content nor is there the ability to optionally check this element for malware. Of the two mechanisms, this option saves system resources for other tasks, i.e. HTTPS Filtering is a much less intensive than SSL Inspection.
- SSL Inspection
The second more complex ‘inspection’ mechanism undertakes decryption of traffic, then the necessary inspection, followed by re-encryption.
The NetPilot/SoHoBlue acts as a secure gateway between user HTTPS web browser requests and the destination web server. SSL content is decrypted and scanned by the gateway device, which can optionally check for malware and also enforces ‘Block’ or ‘Allow’ policies configured in the unit’s Filtering Profiles.
After processing and if the request is not ‘Blocked’, the content will be re-encrypted and routed to the user’s web browser. Because of the amount of processing activity, SSL Inspection has more impact on system resources than the less intensive HTTPS Filtering.
SSL Inspection requires the deployment of a Root Certificate on client devices.