Can i ask how did you go with TAC in regards to " Google, et al and their apps not working with decryption,
I know people are saying wait 2h hous and some of the problem appears to be resolved , however you are saying some problems remain.
To all people who upgraded to 8.0 or 8.0.1 , would you recomened too people to upgrade or are you regreting the fact due to this decryption issue.
The app decryption issue is specific to Android devices running 7 (and potentially any future ones). I tested on an Android 5 device yesterday and all apps work without a problem. This is due to changes in the trust level of client certificates on 7, plus the Android 6/Instagram certificate pinning change. This was the case with PA 7.1.x so upgrading to 8.0.x made no difference to this issue.
This is separate to the wait xx hours after upgrade issue in Chrome/FireBadger. In that regard, the command I posted earlier apparently doesn't resolve the issue, but the TAC confirmed that it didn't reappear after a reboot. Our Chrome/FireMongoose issue just resolved itself after waiting until the next morning.
@DavidMicallef on the Android piece? That is and is going to be broken until Google either relaxes on the trust level of the client certs or otherwise releases a way to actually get this to function correctly. The ball at this point is really in their court to either leave it how it is currently or actually allow people to mitm their own clients traffic.
Both really :) wait hours before ssl plays ball nicely & Android 7 issue.
With the Android issue does anyone know of a whitelist/s that can be used to disable inspection on Google ip ranges / URLs? Although this isn't enough as the vast number of cdn's that apps use will still cause issue. Short of disabling ssl inspection all together I am at a loss in this regard.
In terms of waiting for the SSL to wake up, our ticket was closed as it's working fine after the initial 24 hours and, hopefully, won't return after a reboot. They did reassure me it wouldn't return, but I'll believe it when I see it. I did make the point of letting Palo know that this was a bug and that it should be on the 'Known Issues' part of their release notes.
In terms of Android 7... yeah... a bit of a dead end! The only option is to disable decryption on a test device and use the apps in question. Check the monitor for URLs and add them to a bypass rule. For Google Play, I've got the following:
Quite a big hole in decryption with some of those wildcards, but it's the simplest way of getting the app to work at the expense of visibility.
For us, this has got to go through our IT Committee to decide whether we continue to break these apps and tell users to use a web browser or we allow the apps through encrypted and lose all URL info...
With the Android 7 bit, still struggling on the initial connectivity check once joining wifi, connects fine but phone states "no internet".
Tried excluding from decryption
but no luck. Only passes internet check if "www.google.com" is bypassed from inspection.
URL logs show traffic to
Gareth have also added your suggested domains (thank-you) :-
If the phone does not pass this connectivity check data will be pushed out via cellular if available.
For the initial wireless connection, all we did was add the URL that you've got in your post to a bypass SSL decryption URL category:
That worked for our setup, but we also had to add it, and another, in a 'Unauthenticated Allowed' URL category:
This feeds into a security rule above the staff/students that allow certain URLs out without authenticating.
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!