SSL Filtering vs SSL Decryption
SSL Filtering is the ability to see, make allow/block decisions, and report on https domains. (E.g., seeing that a user is attempting to visit https://www.google.com.)
SSL Decryption is the ability to see the full details of the activity on those secure sites. (E.g., seeing the specific google search terms entered.)
As more of the Web moves to https, decrypting SSL traffic becomes more important to our customers who want visibility into student activity. However, as more providers limit or restrict decryption with their services and devices, this also becomes increasingly challenging. We do and will continue to provide the most powerful filtering solutions across all platforms and offer SSL decryption across platforms, as well as solutions to the issues that can come with it.
The best choice for filtering iOS devices is our Web Filter for iOS app. This uses the latest Apple Filter Provider extensions to examine, filter, and report on network traffic from an iOS device. This requires iOS 9.3 or greater.
The Web Filter for iOS:
- -Filters all TCP traffic for all browsers
- -Offers seamless user identification
- -Works on-site or off-site
- -Works with our Rocket Web Filter or Cloud Filter
iOS Filtering & SSL Decryption
The Web Filter for iOS app provides SSL filtering but does not decrypt SSL traffic. This is a restriction from Apple, not a limitation of our Web Filter for iOS.
If your reason for wanting to decrypt SSL is visibility into search terms, you could redirect google.com to http://www.bing.com or another non-https search site (Google and Yahoo have moved to entirely secure search; at this time, bing still offers unsecure search at http://www.bing.com). This is certainly a temporary fix, as bing is also moving toward encrypted search as well.
iOS Filtering & SSL Decryption with a Proxy
If full decryption SSL traffic for iOS devices is a requirement, that can be accomplished with a trusted man-in-the-middle proxy solution, which Lightspeed Systems provides. It’s a great solution that combines full visibility and reporting with speed and access and it is available across mobile platforms and with either our Rocket Web Filter or Cloud Filter solution. (Learn more about the man-in-the-middle proxy in our SSL, Explained white paper.)
Many customers are able to use an authenticated man-in-the-middle proxy for their iOS and other devices without issue. But some customers encounter authentication issues with iOS devices.
- a. If you’re using GAFE as an authentication source – Google has publicly stated that they do not support GAFE accounts for authenticated proxy.
- b. For other authentication sources, an Apple bug sometimes manifests. This most often manifests as multiple requests to enter credentials (in some cases, every few seconds) – regardless of how or where they are hard-coded in the device; regardless of the MDM in use; and regardless of the filter being used. This issue is an Apple limitation and has been observed on a variety of iOS versions (from iOS 5 through iOS 9.x) and is highly discussed in Apple forums. Sometimes it appears to be fixed with an Apple release, but it manifests in the next iOS release or in the next batch of devices.
At this time, our solution for customers who require SSL decryption and either use GAFE as an authentication source or experience this Apple proxy authentication bug is to create an open proxy (that does not require authentication). This solves the authentication issue, but creates some new ones:
This obviously creates a security weakness on your network, as you’ll have an open proxy running which can be accessed and used maliciously. If you accept these risks as a trade-off of decrypting the iOS SSL traffic, we recommend setting Proxy Security to “Restrict access to iOS and ChromeOS” or “Authenticate external users” rather than “Open Proxy.”
If you choose “Restrict access to iOS and ChromeOS” – this will limit unauthorized access to the proxy, mitigating but not eliminating security issues. In addition, it will not allow you to use that proxy for any Windows devices you have running on your network.
If you choose “Authenticate external users” – this will allow open access to network users, but require external users to authenticate. This will mitigate security issues, but will not eliminate the repeated requests to authenticate, but will limit that to when the device is off the school network.
2. Lack of username in reporting
Allowing access to your Proxy server without authentication gets around GAFE directory restrictions and the Apple bug of repeated requests to authenticate, but obviously it leaves you with unauthenticated users. Whether those are just iOS and Chrome devices or just on-network devices, unauthenticated users by definition do not have a user name tied to them. Therefore, you’ll be able to see specific Google search terms (since it is using the proxy to decrypt that SSL traffic) but you will not be able to see a username associated with that activity on your Web Filter report.
If you’re in a one-to-one environment, you’ll be able to use the reported IP in your Web Filter reports to identify the user based on other district records. If you’re using shared devices, you’d have to combine that information with time/class schedules. And if the devices are off-campus and not authenticated, you’ll see the IP of the home (or other location) where the user is connecting and may not be able to tie that to a specific user.
For enhanced security and visibility, you could couple your open/partially-open proxy with Captive Portal/Web Authentication. The limitation of this is that if you have multiple users in one place, all activity on that external IP will be tied to the first user who web authenticates.
MacOS Mobile Filtering
Mac OS filtering is provided via our Mac mobile filtering agent. Coupled with our Mac User Agent, this provides user identification, filter policy enforcement, and robust reporting whether the device is on or off-network.
MacOS Mobile Filtering & SSL Decryption with a Proxy
If you are using the Mac Filter agent and require SSL decryption, you can utilize a man-in-the-middle proxy to decrypt SSL traffic.
Windows Mobile Filtering
Windows device filtering is provided by our Windows Mobile Filter agent.
On Windows devices, you can combine our Windows Mobile Filter agent and our LMA (for user identification) for user identification, filter policy enforcement, and robust reporting whether the device is on or off the network.
Windows Mobile Filtering & SSL Decryption with a Proxy
If you’re using the Windows Mobile Filter and require SSL decryption, you can utilize a man-in-the-middle proxy to decrypt SSL.
Chromebook Mobile Filter
Mobile filtering on Chromebook is provided by our Chrome filtering extensions and our chrome user extension for user identification. These extensions are easily deployed through the Google Admin Console, like any other extensions.
We have two filtering extension and which one you use depends on if and how you use SSL certificates:
No SSL certificates → Chrome Mobile Filter Extension
Self-Signed certificates → Chrome Mobile Filter Extension
Certificate Authority (CA) Signed certificates → Chrome S-Mobile Filter Extension
Chromebook Mobile Filtering & SSL Decryption
Both Chrome mobile filter extensions offer SSL decryption without the need for a man-in-the-middle proxy.
Android Mobile Filtering
Android filtering is provided via our Android browser replacement mobile filtering agent. This provides user identification, filter policy enforcement, and robust reporting whether the device is on or off-network.
Android Mobile Filtering & SSL Decryption with a Proxy
If you are using the Android Filter agent and require SSL decryption, you can utilize a man-in-the-middle proxy to decrypt SSL traffic.
Linux Mobile Filtering
Linux filtering is provided via our Linux mobile filtering agent. This provides user identification, filter policy enforcement, and robust reporting whether the device is on or off-network.
Linux Mobile Filtering & SSL Decryption with a Proxy
If you are using the Linux Filter agent and require SSL decryption, you can utilize a man-in-the-middle proxy to decrypt SSL traffic.
Where is the Cloud hosted?
Our Cloud Filter is hosted in our datacenter.
Will the Cloud Filter count for my CIPA compliance needs?
Yes, the Cloud Filter will ensure CIPA compliance for all devices on your network (even BYOD/guest devices) and for school-owned devices when they leave your network.
Who can access the Cloud Filter?
Each district is provided a unique URL for their Cloud Filter tier, and only designated district administrators are able to log in to access the filtering controls and reporting data.
Is my data stored separately?
Is the Cloud secure?
Can I use the Cloud for trusted man in the middle proxy and SSL decryption?
Yes. See details below.
So the Cloud Filter is a DNS redirect?
No. DNS filtering is just a part of our Cloud Filter, provided to ensure safety, appropriate use of network resources, and CIPA compliance on guest networks, BYOD devices, or devices that can’t have an agent installed. For most devices, an installed mobile filtering agent will provide more comprehensive and granular policies and reporting than our cloud DNS feature.