Note: The original post has been modified to reflect the latest information and status from our conversations with Google.
Disclaimer: this is a long post, but filtering and accessing Google services is a top concern for our customers, so I wanted to explain things clearly and in detail.
Google is actively moving all of its services to being delivered over a fully encrypted (https) connection. Many of these services have been encrypted for some time and we have made it a priority to work with Google to help them move these services to encrypted connections in a way that allows schools the effective web filtering they need. While we work with Google to create these solutions, we have added features to the Web Filter to work around the issue. One example of this is the failsafe feature that is an option in our Web Filter policies.
As Google began moving more of its offerings to encrypted connections they did make one change to their implementation that made differentiating these services possible. This was to utilize an extension to SSL called SNI (Server Name Indication). Without using SNI, the only information the Web Filter has to evaluate during an encrypted connection is the IP address and the certificate name, which in most cases including Google is a wildcard certificate (*.google.com) identifying the domain name but not the specific host. When SNI is enabled the Web Filter is also provided with specific host that the user is accessing, such as mail.google.com or drive.google.com. This allows a school to apply differentiated policies that will allow, for example, an encrypted connection to Google drive but block the connection to mail.google.com.
For some time this has provided schools with flexibility they were looking for in applying policies on use of Google services. Initially the only limitation to this was the fact that Internet Explorer on Windows XP did not support the SNI extension. This was a decision made by Microsoft to not update the operating system to support this. In response to this problem we added the Google Failsafe feature to our policies. This puts an additional protection in place so that if a user is using IE on Windows XP and they attempt to access an unidentified Google Service, the school can choose to either block or allow this traffic. The school also has the option of installing any other browser on Windows XP (such as Chrome or Firefox) for proper identification of the encrypted connection.
When the primary devices on a school network were desktop and laptops running Windows, Mac OS or Linux, this solution provided a good balance between protection and over blocking. Today schools face new challenges in dealing with Google Services. Google moving more services to encrypted connections, as well as the introduction of mobile devices and specialized apps such as the Google Play Store on Android or the Google Drive app for Windows, limit the use of these options because support for SNI in these specialized apps varies greatly. Some versions of the apps will support this and others will not. For those apps that do not support SNI the connection looks very similar to the IE on Windows XP where the traffic can only be identified as a generic encrypted Google connection and selective policies based on service can’t be applied.
I recently had an opportunity to discuss these difficulties with a Senior Product Manager at Google and he not only recognized that these issues are causing difficulties for schools but he said he will talk to the leaders of all the various product groups to make changes on their side to resolve them.
So what does this mean for school customers? There are three primary options:
Option 1: Find the solutions and services that work best in your district, and use redirects when necessary to point users to your preferred solution.
Option 2: Continue to use the Failsafe option. Schools that have not adopted Google Apps for Education (GAFE) and are not widely using Android-based mobile devices will probably not have any negative impact.
Option 3: Utilize the proxy mode in the Web Filter. By running the Lightspeed Systems Rocket as a trusted Man-In-The-Middle encrypted proxy, the school will have full access to the URL that the user is accessing and can fully identify the resource and make differentiated policy decisions.
I would also like to point out these issues are not unique to the Lightspeed Systems Web Filter. These challenges will exist in any web filtering solution. At Lightspeed Systems, we are committed to providing schools with effective web filtering solutions-as well as bringing issues such as this to your attention when we discover them. We will continue to advocate for schools whenever we have discussions with Google and other service providers. We will continue to monitor their encrypted implementation for any changes that will make these services more effective for schools and we will make any necessary changes in the Web Filter to support this.