- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
01-09-2020 03:44 AM
As part of our setup, at an independent school, we decrypt the majority of traffic and set rules to bypass where needed. As part of this, we've struggled to get the Google Play Store to work with decryption turned on. I've used a test phone without decryption and reviewed the URL logs to determine which URL(s) may need adding to a bypass rule. After lots of testing with lots of different URLs we found that bypassing the 'www.google.com' domain made it work. The trouble is, we don't want to bypass www.google.com as we will lose visibility on searches and other traffic information that we need as part of our safeguarding role. Has anyone else run into this problem or found a way to get it to work without losing the root domain visibility? Any help would be gratefully received.
Regards,
Gareth
01-09-2020 09:35 AM
I am currently working on this as well and probably ran into the same issue as you did.
I was having log in issues so if you haven't done so already, you'll need to white list the URLs found here.
https://support.google.com/chrome/a/answer/6334001?hl=en&ref_topic=3504941
Once I white listed these URLs, I was able to sign in and noticed that the Google Play Store was not working properly.
This fixed my issue for me.
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CmJQCA0
Hope this helps.
01-09-2020 10:52 AM
I truly believe, from a technological perspective, that Google is using proprietary encryption techniques that will cause PANW SSL Decryption to fail.
It simple terms... I am not sure you are you able to properly decrypt google related traffic.....
01-10-2020 12:10 AM
Thanks for the links @keevang, I'll give them a try today and lee you know how I get on. It might also solve our current youtube app problem as well!
Regards,
Gareth
01-17-2020 09:17 AM
dind't help. I have a lenovo tablet and it shows no network till I remove www.google.com from the decryption list.
01-21-2020 08:13 PM
I've been working on a project where i had to put some restrictions on the network for BYOD and managed kids' devices. Palo works perfectly when it comes to enable SSL Dec on PCs, but then nightmare begins with smartphone/tablets.
Effectively, the aim was to implement for kids' user group youtube content filtering (minemeld), + safesearch and allow as much BYOD devices as we could. I concentrated on android devices first because it was easy to import the root CA cert into them, however, there are a LOT of native apps that use embedded certificate pinning. Most of native google apps are using quic protocol (and udp/443) instead of SSL, and unlike Chrome browser they don't fall back to SSL if quic is denied, they simply stop working. Google Play Store is one of them. If you don't allow quic protocol, it won't work.
The most annoying thing that every device has sort of a built-in small http/https browser that is coming up when WiFi is on, and the first thing it does, it checks the accessibility of www.google.com. The worst part is that this built-in browser doesn't look into the inported user Root CAs certs, and if you have SSL Dec on www.google.com, it won't be able to get the response and you will get this small cross icon on your wifi picture on the phone saying that "the internet may not be available". The internet will work actually on the device, but it appears that many apps tend to detect the internet state using some Android API, if you have this cross on, your google play won't work, some email apps won't even attempt to download email and other irritating stuff. I had to implement a special gstatic url category with a long list of urls, where various devices are trying to go, and disable SSL decryption for these URLs. Unfortunately, so far i couldn't find a way how can I enable SSL dec for www.google.com
Another pain in the arse is Android GlobalProtect VPN client that has to force all packets going over VPN even on 4G connections. Yes, you can configure it in always-on mode and deny signing out, but... the app simply can be uninstalled by a phone user. Or just stopped, or killed, or kids can run angry birds on their Samsung S5 and GlobalProtect silently dies. This is annoying and completely diminish the always-on idea. Yes, Palo recommends to use MDM, but if you have 10-15 devices, deploying MDM is jsut another instance that you will have to look after. Eventually, I deployed a free MDM server, but it's happened that GlobalProtect is not killable/dying only when you make a device as a device owner, so it's not so suitable for BYOD devices. On BYOD devices MDM is supposed to create a work profile... a good idea, but only if devices have android 7 or higher. The mentioned Samsung S5 will not have any work profile and you can't lock out the always-on VPN. Another Android 9 based phone from ZTE simply will not create the work profile. Maybe a firmware bug, who knows, but you can't accept such device then. So, i'd say the attempt to lock down the GlobalProtect app and it's vpn on BYOD devices is not successful.The only way to make it working is to enrol the device as device owner and that means full factory reset of the device before enrollment.
Palo should consider how they can harden the app install, maybe make it into the admin mode andprevent it from killing. It should not rely on third party MDM solutions.
The only way I eventually found how to make the final solution acceptable is to run all this in conjunction with Kaspersky Safe Kids. Unlike GlobalProtect app, it's just not possible to kill/uninstall Kaspersky. It's running all the time, it can block certain app, it can filter what is requested in browsers, and you can even set up how much time each app can be running for.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!