- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
02-22-2017 09:07 PM
Out of curiousity...Doesn't seem too technically smart for a firewall / security appliance come built-in with 121+ Internet based domains to include foreign domains which are automatically excluded from SSL Inspection:
From the user help doc:
Predefined decryption exclusions allow applications and services that might break when the firewall decrypts them to remain encrypted. Palo Alto Networks defines the predefined decryption exclusions and delivers updates and additions to the predefined exclusions list at regular intervals as part of the applications and threats content update. Predefined exclusions are enabled by default, but you can choose to disable the exclusion as needed. |
02-23-2017 06:23 AM
I agree that this should be an opt in feature; but I would guess that the majority or PA customers that enable SSL Decryption do so simply by following the live guides on how to do it. In this case you would want to have it 'just work' to avoid any support calls from people because such and such website is broken because they didn't exempt it from decryption.
Most people that actually know how to setup encryption and would 'care' about enforcing strict security policies would likely do the research on it first and decide if they wanted to take the default exemptions or not. I think it's likely more of a compromise thing.
02-23-2017 03:34 PM
I agree, deny all and allow only by exception. Perhaps they can/will change that behavior in the future if we put in requests?
02-23-2017 11:24 PM
A couple of thoughts on this one:
PAN-OS 8.0 actually takes a step in the right direction here. In the previous version of PAN-OS, this information was only available via CLI. In 8.0 this list is now exposed via the GUI,
Also keep in mind that the default inter-zone security policy blocks all of these applications. And, if you follow the documentation on SSL Decryption, you'll be well-informed on the existance of this list and the reasons for it. The nice thing is that it takes only 2 clicks to disable all of these exclusions (well, 4 if you include commit + ok).
02-23-2017 11:34 PM
If i understand correctly these exclusions are only for applications which don't work if SSL decryption is applied to them? In that case it's the right move to have all these exclusions enabled.
If you don't want to allow certain application -> block it in security policy.
If you want to allow certain application -> you want the exclusion enabled otherwise the application won't work.
02-24-2017 05:03 AM
@santonic my thoughts exactly. If the application is unusable with ssl decyrpt turned on, then there really isn't any reason to allow someone to inadvertently turn ssl decrypt on. Trying to troubleshoot something that PA knows isn't going to work seems like a lot of waisted time.
02-24-2017 11:44 AM
I'm all for PAN to advise admins/consumers of their products that, "hey, these 121+ websites (Some of which include cloud hosting services) do not work if SSL decryption is enabled."
Where I think this goes wrong is in enabling it by default, while at the same time not telling anyone. It's not in the "Changes to default beavior" or in the new features breakout. So the only way any admin finds out about it is by examining every aspect of the config (which I agree anyone should do.)
However not all admins are equal and I bet more than half won't even really notice this. Not to mention this exclusion list grows at least weekly which with Dynamic updates. This means each week admins need to check to see if PAN decided to modify my security policy by exempting websites from SSL inspection.
02-25-2017 05:09 AM
Having experience with SSL decryption and the challenges it presents, I am in the camp that this is a good thing. Anyone who enables SSL decryption without fully understanding what they're doing will face much larger problems than having a chunk of sites not decrypt at all. And even if you choose to not exempt them, they're likely not to work at all and it may be more work trying to track down why it isn't working.
My larger concern (and really the only reason why I'm replying) is if that is in fact the default list, it bothers me that not only does it appear to allow hostnames to be entered in mixed case, it's case insensitive which leads to there being 2 yuuguu.com for example and I'm not even sure what the heck kind of hostname 'SoftEther VPN' is.
unless I'm missing something of course.
02-25-2017 01:34 PM - edited 02-25-2017 01:41 PM
(I have 15 years of administering SSL Interception on an enterprise scale of networks from 4,000-25,000 users...This feature runs counter to everything that an admin would want....If I were to use Palo as my MSP, then sure I'd like them dynamically update my security policy)
I agree with you Bradk14, If Palo has done extensive testing and knows that these currently 121 websites doesn't work with SSL Interception that exempting them isn't an issue, but it's all about awareness/understanding of a network's environment.
This feature creates a blackhole for admins, which inherently creates unnecessary risk.
There have been KBs about how certain applications don't work if they're intercepted like the Dropbox thick client.
In the same vein why weren't those things exempted from SSL Interception? ...There's just something fundamentally wrong with an outside entity creating exclusions to what a security appliance can see.
Palo talks about how for the best security and ensuring the appliance can use all features to protect an environment SSL Intercept traffic, yet in one fail swoop they're exempting cloud hosting services from interception; which creates a big unknown for the very security features which Palo sells in services subscriptions to the same customers they're creating the lack of visibility for.
I just think this feature should be an opt-in thing...Like the SSL port-mirroring. Let the admins know it's out there; and if they so choose enable the auto updates to the exepmtions.
02-26-2017 04:08 PM
This new feature is designed to help whitelist sites that will normally NOT WORK with decryption due to technical reasons - such as pinned certs, client side authentication with certs, etc.
As customers are also using their Decryption Policies and Decryption Profiles to perform decryption classification (what to decrypt), how to handle certificate errors, which cipher suites to use, etc, this feature isn't primarily used to police what should and shouldn't be decrypted. The decryption policy/profiles and URL filtering categories are all still used to perform the "what should be decrypted" policing.
The logic behind this feature is to not break the user experience if the other policies are ALLOWING the user to go to the site. If they're allowed, this feature simply allows the user to go to the site without having it break as the firewall will not be able to decrypt the session due the certificate issues mentioned.
Of course customers can still disable these sites and have them break as before. But many of our customers wanted the default to ALLOW the user to access the site by whitelisting as the site is a trusted and permitted site.
Thanks
02-27-2017 01:14 AM
Hi,
This is not entirely new. In pre-8.0 version this list also existed and it had the same default behaviour (exclude from decryption).
In pre-8.0 however you couldn't change the default behaviour.
PAN-OS 8.0 made the list visible in the GUI and added the possibility to disable the exclusion.
-K
02-27-2017 06:23 AM
Thanks Kiwi for the clarification. Agree...The changes in 7.1 where the "reason for end" which illustrates certificate issues as well as features like this which give greater visibility to admins in the GUI is always a good thing.
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!