I had enabled ssl decryption and no issues with desktops. But, Android phones have issues with apps like youtube,DUO etc but can browse through chrome.
I assume this is because of certificate pinning that these apps use. Please correct me if I am wrong and also is there any way to resolve this besides excluding the URL or IPs?
A lot of mobile apps can actually introduce their own app-specific certificate authority similar to how Firefox does things. In the case of DUO it's highly likely they are either using cert pinning, their own CA, or a combination of all of those.
Essentially the only reason to really fix it is to excempt it; you simply can't MITM this traffic.
Excluding the URL's or IP's is the best option. There are a bunch or APP's that the PAN will not decrypt implicitly because they do break, just not sure if those apps are on the list. Also do you have your trusted cert that the PAN uses to decrypt on the androids?
Here are a few links that I use:
This one has a link to the applications it wont decrypt.
I'm sure you have already found those however.
Thank you for your responses. Yes I have cert rolled out androids in trusted root ca store and I do know excluding urls and IPs should resolve this but these androids are on a network along with laptops. I can't really exclude neither *.google.com or entire Ip subnet. I am a deadlock situation now. I was wondering if I can exclude them by user-agent but that doesn't seem like a feasible option.
This can be tricky. however I am assuming the androids are on wifi. That said we have our Wifi on a differetn subnet so that we can create policies around just it. At the last place I was at, we had policies based on user-id and if it didnt match, they got stricter policies.
Version 8.0.x you can only specifiy decryption filters on zones, ip address or range, user, or url-category. I'm sure there is a happy middle somethere?
I would say its OK to decrypt them so you can still see the traffic and stop any bad things from getting in or spreading. At the same time have a no-decryption policy to bypass some of hte stuff you know cant be decrypted. For instance we dont decrypt any URL's in the catagories, military, financial-services, government, or health-and-medicine.
Hope that helps.
This approach doesn't look feasible when you have one WLAN for mobile and laptops. How are you going to differentiate who is who ? Win/Mac based laptops are sitting in the same wireless network as android/apple smartphones.
To be honest, while SSL decryption on PCs is working reasonably fine, Palo has huge problems with mobile devices, e.g. android/apple smartphones. Most of apps simply don't work with SSL Dec enabled and it's a pain to find out what to unblock for a particular app, and it's not reliable at all. Google is rapidly moving on implementing QUIC everywhere, and if I block QUIC app, google play app simply stops working.I will post separately a lot of issues I'm currently stuck in when I enabled SSL Dec for mobile devices.
I see 2 feasible ways to fix this:
1. Palo will allow fallback to normal unencrypted ssl mode if it can see "decrypt-error" in logs.
2. Palo will implement informing the firewall using GlobalProtect App about the platform is being used, but there are 2 issues:
- GlobalProtect now can be simply switched off by the Android OS or by a user even it's in Always-on mode. I have a number of phones that have GP just not working. Palo sould look into a better protection from interaction between users and GP. Look, for example, how Kaspersky Safe Kids app is implemented. You simply can't switch it off. It's always running and there is no way to kill it without proper authorization.
- we will still have problems with users who don't have GP and getting authorized using Captive Portals.
So, don't know what to say. While PAN FW is awesome for PCs, it's really weak in the world of mobile apps. Even Checkpoint SandBlast works more reliable than GP.
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!