There are a number of Domains/SSL Certificates that are excluded from SSL Decryption.
Starting with PAN-OS 8.0 and newer, the SSL exclusion is handled inside of the Certificates section of the WebUI.
To see the full list of domains/SSL certificates that are excluded from SSL Dectyption, Inside of the WebGUI > Device > Certificate Management > SSL Decryption Exclusion.
The domains selected with the "Exclude from decryption" in this location will not be decrypted by the Palo Alto Networks device.
This list of domains are added the SSL Decryption Exclusion list in each Content load so that the SSL engine will allow them to pass through, rather than trying to decrypt them.
In PAN-OS 7.1 and older, applications were used instead of domains.
These applications are added to an exclude list in each Content load so that the SSL engine will allow them to pass through, rather than trying to decrypt them.
Open a case with your support provider if you have a site that should be added to the list.
Is there a reason why these sites cannot be decrypted ?
Generally they can't be decrypted because they deviate from SSL encryption standards. They may use proprietary encryption, require a specific type of certificate or be unable to add new certificate authorities. Decryption would break them so that they no longer work. This list can't be manipulated to force decryption.
Question : do you first check for SSL certificate validity ?
Imagine a hacker creates a self signed certicate for *.dropbox.com or *.gotomeeting.com or any application listed below.
Since you don't decrypt it, he would be able to tunnel anything he wants.
I stumbled over this entry by accident and I must admit that I'm surprised to see yet another "undocumented" default action from Palo Alto.
If I define a policy to decrypt all SSL traffic I expect the device to do what I specify. I fully understand that this could break certain applications, but as a security admin I expect to be in full control without a device changing the policy I define.
Is there a way to override this so that the device decrypts all SSL traffic without any default exceptions which I prefer to define myself?
When you define the SSL decryption policy enable the "Block sessions that can not be decrypted" option. This will cause the firewall to block the session if either the certificate matches the exclude list, or the firewall is unable to decrypt the session for another reason.
kfindlen , I would not bet on that as I know Dropbox will pass even I enable Block if cannot decrypt.
As of 4.1.7, I'm still seeing decryption issues with Dropbox and AOL AIM. Is there something I have to do to enable this list?
I currently have Dropbox's netblock set to not decrypt ( http://whois.arin.net/rest/net/NET-199-47-216-0-1/pft ) but I haven't figured out bos.oscar.aol.com since it doesn't have an A record yet I can clearly see this in the Pidgin logs.
You can put *.dropbox.com in a URL category and then disable Decryption on that new category
I think what is throwing me off here is the log file. In the Monitor/Traffic I see the dropbox traffic as allowed. However, that is allowed through a higher rule that is my executable file blocking to sites in the unknown category.
If I pull up the details on that log, there is an addition deny log entry from a rule further down which is blocking the category of personal storage.
I must be doing something wrong on my traffic view. How do I see all the logs, including the deny? I do have logging set to "Start" and "End" on both of these rules.
For FedEx Shipment Manager to work, the following should be removed from Decryption:
Reference: FedEx Ship Manager Software - Astaro User Bulletin Board
Anyone still having problems with Google Chrome?
According to the 4.1.8 release notes PA fixed the problem but I still can't use the Chrome Omnibox for Google searches.
Typing a search item redirects to
https://www.google.ch for me and I get a Certificate Error.
Clicking the lock icon shows everything as OK, the PA CA is trusted by my browser. I also disabled SPDY and used the command line switch to use the system SSL.
Even specifying *.google.com and *.google.ch in a rule to exclude SSL decryption didn't help.
I'm also getting the same error message now with the latest Firefox.
Currently the only way for a Google search is to use IE with an URL like http://www.google.com
Don't use SSL Decryption against Google services (it's been creating problems for months, especially with .country version) , you need to wait for PA to implement missing SSL features for that.
Just bypass decryption for all google ranges: ip4:188.8.131.52/19 ip4:184.108.40.206/19 ip4:220.127.116.11/20 ip4:18.104.22.168/18 ip4:22.214.171.124/17 ip4:126.96.36.199/20 ip4:188.8.131.52/16 ip4:184.108.40.206/20 ip4:220.127.116.11/20 ip4:18.104.22.168/16
What is the status for a fix for this? Disabling decryption for google services/sites is a no go for companies that have regulatory needs for decryption to stay within regulatory compliance. Is there a way to create a rule such as (if useragent = chrome and spdy = true then do not decrypt)? I am very new to PAN so I am not sure if that is even possible. At least we can get to most sites and just not decrypt sites that have implemented spdy.
The fix is being handled as a feature request, don't expect it happen very soon. I am pushing for it as a customer but it's true that they need enough time to develop a rock-solid enhancement in their SSL stack.
Way back in the day when HTTP/1.1 just began to be utilized, I had an option in my eSafe gateway where I could disable HTTP/1.1. The eSafe box would tell the browser the server was just HTTP/1.0. They did this until they had time to build code for inspecting the GZIP, COMPRESS, and DEFLATE capabilities of HTTP/1.1.
I want to add my voice to the mix. We really need to see Palo Alto step up to the plate and address this traffic. Decryption was a big selling point. I would be happy if I had a check box on my Palo Alto where I can disable SPDY alltogether and then the Palo Alto modify the servers ServerHello response to remove the spdy/2 response
This is an important feature for me.
I agree with EdwinD that would be a great option and it is a must for me as well since our corporate standard is Chrome.
Another that needs excluded from SSL Decryption by default is https://softwareupdate.vmware.com/cds
Without excluding this, VMWare products fail to check for updates and fail to notify users that security updates exist. A manual check will result in "Disconnected - A certificate error occurred for the update server."
This should be excluded from everyone's SSL decryption as otherwise it presents a silent security vulnerability into a network.
Is there a property on the apps that defines whether or not it is decryptable? better to work with decrypting specific apps instead of writing exceptions to a blanket rule.
Come on, this built in "SSL engine pass through" is ridiculous beyond belief. I can understand publishing a list of troubled apps and their associated sites but to force this pass-through is just wrong and needs to be fixed.
I'm on the side of PA on this one... if the SSL implementation is not known (because it's somewhat proprietary) and therefore the traffic can't be decrypted, then how do you propose PA "fixes" this other than deliberately passing through this traffic? We do SSL decrypt (not with PA devices but with a different device) and we've always had to make exceptions such as the one described in this post because of funky SSL implementation.
We have a squid server behind our pa fw like this:
Client <-> PA FW <-> Squid Proxy <-> ASA FW <-> Internet
Decryption of site https://addons.mozilla.org adds the IP address of our squid proxy to the exclude-cache list and all following ssl connection are not decrypted anymore. Is this expected behaviour?
I'm not decrying the fact that certain SSL sessions break when decrypted and that they need to be excluded from the decryption process if we must have them work.
We want visibility to everything so we have a default decryption policy that blocks the traffic if decryption fails. If a site/app breaks because of decryption, we assess the risk and decide if we wish to exclude it from decryption in a policy.
What confounds is that this 'feature' circumvents the configured decryption policies,.. we have not decided to let that list of sites pass through. This means I must know exactly what is in the exclusion list and add a security rule to block those sites that we have not deemed permissible.
Ahh! That makes sense. That's definitely a reasonable reason to complain about this list then :smileyhappy:
azwicker - honestly a question like this would be a candidate for its own thread, in the Discussion Forum, not as a comment on a document
Is anybody else having problems decrypting Juniper SSL VPN traffic?
It is not on the list but the list is old.
BTW, I'm still convinced that Palo Alto should give us control over bypassing decryption for broken sites and don't let the traffic pass through undecrypted.for some obscure list of sites.
AndreasB - You do have the control to bypass decryption with an SSL decryption policy. If you have not set one up you will need to as there are always randoms sites that can't be decrypted properly. You just specify the addreses in the destination address policy and use action no-decrypt before the decrypt policy line entry.
the problem is that there apparently is a list of sites/applications (does it still exist in 5.0.x?) which are not decrypted by default and this is a built in feature not under the control of the security administrator.
I'm perfectly fine with the fact that some sites/applications don't follow the standards and can't be decrypted, but this must be controlled by the admin, not by the vendor.
If your firewall policy is configured to allow app XYZ and attempting to decrypt it would break XYZ, then the firewall would no longer be allowing the app you intended to allow.
If you feel that a specific app should not be allowed because it does not work with SSL decryption, then you can create a firewall policy to block that application.
The issue is we don't know at any given time what applications the vendor has excluded from decryption. Without this information we cannot properly maintain the policies in our firewall.
If we check out Watchguards document we have a clear explanation of why certain traffic cant flow through the Palo Alto decryption.
Basically, while DropBox.com in IE may be fine when decrypted by the Proxy CA, the DropBox app itself doesn't work. The app validates the authenticity of the signing certificate authority whereas IE is using the system certificate store.
One can't simply setup an IP or IP range to address this as one would in the old days because DropBox is hosted in the Amazon Cloud. Some of it uses SNI. One would be whitelisting an enormous amount of other websites if one took this approach.
This is going to become more and more of a problem as vendors attempt to thwart MTM Proxy CAs.
I suggest that this list in DOC 1423 be a tab within PanOS. As Palo Alto updates this list of applications, the relevant tab is updated. As a user, I have the ability to put a check box next to an entry which allows me to decrypt and thus break individual apps. This could be because I have an enterprise policy blocking everyone from second-life.
The other reason this needs to be more visible is because I have ancient PanOS 4.0 rules in place to address gotomeeting decryption issues. Palo Alto updated this list and I had no idea. At this point I could remove or disable my complex decryption rules which prevented gotomeeting from being decrypted.
I'm sure PLM is looking at this, however as things stand right now you shouldn't be *relying* on SSL decrypt to 'break individual apps'. Your best bet with the current feature set is to use AppID and firewall rules to block applications you don't want to allow, and use SSL decryption to decrypt things that you want a deeper look at.
Look at it this way, before an application can even hit the decrypt policy, a firewall rule has been put in place that allows it. Having a separate feature (in this case SSL decryption) break/block an application that you've explicitly allowed is sub-optimal. Fortunately if you want to block it yourself, you still can.
Also, you'll note the list above does not have Dropbox on it - I'm not sure where that came in to the question, but Dropbox traffic through a browser can be decrypted by a Palo Alto NGFW just fine, so we do that.
It is very misleading for Palo Alto to say this is a list of applications that are excluded from decryption. Try creating your own exclusion decryption policy based on what the application is... it isn't possible. The Content load exclusion list is actually a list of IP addresses. When an encrypted session is initiated to an IP address in this list, irrespective of the application, the session will circumvent the configured decryption policies.
Dropbox was mentioned because Dropbox is a perfect example. The app doesn't work when decrypted by PanOS. The details are right on Dropbox at this link: https://blogs.dropbox.com/dropbox/2014/06/weve-got-your-back/
Another post about this is here: https://groups.google.com/forum/#!msg/httpfiddler/1A8Aks8ymPY/ZalTbWW0DV4J
While in this case I am talking about an App and not a website, websites can pin too. I'm very curious how Palo Alto Networks is going to handle websites using certificate public key pinning and TLS_FALLBACK_SCSV. I'm already running into websites that use these technologies and thus will not even connect through the Palo Alto Networks firewall with decryption enabled. It seems to me that as these two technologies become more common place, there will be no way to decrypt many websites.
As Microsoft is doing with Windows Updates, Symantec is pinning their private signing certificate into their products. SEPM Antivirus has pinned certificates within the product.
Decryption of the following websites causes this pinning to detect Palo Alto Networks SSL decryption and the related functionality fails.
I suggest Palo Alto Networks add these specific hosts to their List of Applications Excluded from SSL Decryption.
Any chance of additional applications being updated or is there any other recommended guidance to deal with applications that utilize certificate pinning? I've had to exclude the following domains for some applications to work properly and I'd rather not play whack a mole with domains and applications:
adobe.com - Creative Cloud and various components of it don't like being decrypted
*.mozilla.org - Firefox in particular doesn't like to access developers.mozilla.org or several other subdomains
*.google.com - google drive will not function unless you disable decryption on several google domains, unless you run a command switch for it to not care about certificates
*.apple.com - Software updates for iOS and OS updates for beta users of OS's was problematic until we added this to the bypass list
Great list TheDave, thanks. Here are some additional sites that recently started using HPKP:
*.youtube.com (along with all other Google properties, like you mentioned)*.outlook.com*.bing.com*.yahoo.com*.twitter.com*.wikipedia.org
This list will only get longer and longer, until there is nothing left to decrypt. I hope Palo Alto will come up with a solution besides whitelisting everything
Please add the following *.join.me and spideraok
we've just found that the latets ms-lync (skype for business) is also failing if we enable ssl decryption.
Hope it will be solved someday.
has anyone infos about MS OneDrive cannot currently decrypted and is therefore built-in excluded?
This application is currently not listed in the exclude list above.
Decryption is becomming. Every week we are adding 1 or 2 more sites that won't work with decryption turned on. We are up to 93 sites that can't be decrypted.
It appears that origin is not fully bypassing the decryption process. The chat portion of the origin client never loads when decryption is turned on.
Is anyone else seeing this ?
I'll be grabbing a flow basic on the traffic to verify what is going on.
Can anyone tell me if i'll still be able to get granular with twitter on mobile devices if it's being excluded from ssl decryption. Basically i want to allow reading of posts but not posting?
Seems that there is still no fix for ms-lync-online. We had to get around it by a exclusion of lync.com & *.lync.com. Will these be added to the exclude list the future?
It seems that the list above is not maintained anymore? What about Signal, dropbox and so on?
I've updated the list and added signal, dropbox however is not in the list
We have run into a problem with Citrix's GoToMeeting/GoToWebinar/GoToAssist/FastSupport. It started on Nov. 30, 2016.
When adding a PC to a list that excludes it from a decryption policy the applications listed above will work. When that PC is removed from the exclusion and is having it's traffic decrypted then none of the applications work.
We have added the URLs listed in the link below to a custom URL category to exclude them from the decryption process.
After excluding the URLs from the decryption policies the issue is still present. We have opened a support case with PAN support and are waiting for a callback.
Has anyone run into this issue?
I've also seen the issue with GoToMeeting. Definitely needs to be excluded.
Cisco Spark is also using certificate pinning. The app forcably exits with a certificate warning on launch. It absolutely needs to be excluded as well.
Please report this issue through a support case so TAC can investigate and appropriate actions can be taken, thanks! :)