As a former district Technology Director, I understand the struggle between keeping students safe and monitored online, while still providing access to important educational tools. This is actually the mission of Lightspeed Systems—to equip schools with the tools necessary to create safe, collaborative, and mobile learning programs.
Working in the trenches with district technology leaders who use Lightspeed solutions, I have recently noticed frequent questions surrounding policy decisions on https sites—specifically issues regarding Google apps on encrypted sites. I can certainly understand the confusion around this topic. In order to best explain it I will start with a little background information and description of the problem.
First, I would like to start with an explanation of how the Lightspeed team makes policy decisions on encrypted (https) sites.
When a web browser connects to an encrypted site some of the initial connection information is sent in clear text between the client and the server. The specific content of this exchange varies based on the capabilities of the client and the server. In the most basic types of connection we can only see the certificate exchange. While the certificate may reference a specific host most companies use a wildcard certificate such as *.google.com or *.chase.com. For most sites this is enough information to make a proper web filtering decision. In the case of chase.com<http://chase.com> we know that it is a financial site so it is a simple matter of checking the policy to see if this should be allowed.
Google is a notable exception to this because they offer a multitude of services including docs, calendar, mail, searching, and YouTube that all utilize the same certificate of *.google.com. Because they all use the same certificate it is impossible to tell which service a client is attempting to use based on the certificate alone. So if that is the only piece of information an administrator has to go on then they are faced with an all or nothing situation. With certificate checking alone an administrator cannot have a policy that blocks encrypted YouTube or encrypted searching without also blocking Google Docs.
The good news is that Google has implemented additional services that allow for greater information to be exchanged between the client and the server. This service is called SNI or Server Name Indication. By utilizing SNI Lightspeed can now determine which of the Google services that the end user is attempting to access. This allows an administrator to block encrypted searching of YouTube or the Web but allow Google docs. Unfortunately this comes with some bad news as well. If the web browser in use does not support SNI the servers will fall back to a simple certificate exchange and once again it is not possible to distinguish between the services. Unfortunately, one of the most common browser and operating system combinations we see in use, Internet Explorer on Windows XP, does not support SNI. In order for IE on XP to support this it would require operating system changes that Microsoft has stated that they will not make.
Here at Lightspeed, we have worked with Google on alternative solutions to resolve this and some progress has been made. An alternative method of blocking encrypted Google searching has been enabled, but unfortunately until Google makes additional changes it will not prevent encrypted YouTube searching.
If you are a Lightspeed customer using browser and OS combinations that support SNI you should be able to selectively access the various services that Google provides.
As always, the Lightspeed support team is ready to assist you in the configuration that best fits your environment.
If you would like additional information we have more details available in this Knowledgebase article
Looking forward to diving into even more tech talk with you.