Whats PAN's future for TLS decrypt with many sites now moving to Diffie-Hellman based ciphers ONLY?

[CMG]

Does PAN have any plan for better managing the current state of TLS decryption now that Diffie-Hellman based ciphers are becoming the default standard?

PAN currently only supports the below ciphers, and when presented with a website that ONLY supports DH ciphers it appears to just reset the connection instead of failing open. Manually whitelisting/ excluding sites which only support DH ciphers these days is starting to become a too labour intensive manual process..

TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA

Does PAN have any plan to better manage this? 

Shouldn't "active" forward proxies be able to to support DH from proxy to website?

Or should we just consider this the death throes of PAN's gateway decryption/ visibilty functionality?

[nwsol]

We are having the same doubts about pan-os.

Every week we have to exclude sites from decryption because they switched ciphers and now only accept DH ciphers.

Slowly but surely this renders palo alto's decryption functionality useless. We were hoping for palo alto to catch up with version 7.0, but their SSL decryption remains flawed (and not only the supported ciphers part).

[ITCMPHC]

Same thoughts here as well.

Each week we had to add increasingly more sites to non-decrypt policies. Eventually we unchecked the "Block unsupported cipher suites" in the decryption policy in hopes of allowing these sites to still work but just not be decrypted. Unfortunately in 6.x, this setting appears to be bugged and the site still won't load. We were recommended by support to move to 7.x, where they said the issue was fixed. We moved to 7.0.2 and found that these sites wouldn't load on first attempt, but a browser refresh would then successfully load it. Not great, but better than before.

Unfortunately a month into running 7.x, we ran into a bug in which our Palos began depleting a certain buffer and would stop processing all SSL/TLS traffic for ~10 minutes. At first this issue happened once or twice a day, but now I've seen it occur as many as 15 times in one day. Early on I wrote a program to monitor for this buffer depletion and fail-over as needed, so none of our users actually experience issues with it. I don't like the fact that I'm having to invoke HA fail-overs so many times though. Failing back to 6.x isn't really an option due to the length of time to see this issue after we upgraded to 7.x and the amount of changes we made within that timeframe. Support assures me that this issue will be fixed in 7.0.3.

I've lost a lot of faith in PAN's ability to stay up with current technology and publish quality releases. Minor bugs are one thing, but when every release has bug fixes related to dataplane restarts, race conditions, memory leaks, etc... It's just getting to be too much for a critical system. You could say not to update to the latest and greatest, but these kinds of bugs have been in every version. We had them in 5.x, 6.0.x, 6.1.x, and now 7.x. Also with certain things like trusted root certs being tied to software upgrades, you really need to stay up to date.

I have a datacenter firewall upgrade project coming up, and I was really considering putting in PA-5060s or VMs for SDN. At this point I've pretty much dropped PAN from my options because I can't afford to have the same issues in the datacenter that I've had on the perimeter. 

Ultimately I really hope PAN can work through the current issues and put in a better QA process. I'd imagine they're going to have to completely revamp their decryption methods however.

[Brandon_Wertz]

Not only that the "error" that pops up within IE basically doesn't provide any info to the user that this non-support from Palo is the problem.

Further within your decryption profile you should be able to say "don't intercept" for unsupported ciphers, but that's a joke.

I opened a case and TAC bascially said yeah it's not working.  You just have to add the sites as you come to across them to the SSL bypass.  He also said 7.X has better support, but seeing all the current issues I'm not about to migrate my entire enterprise to a version of code that has more problems than it's worth.

[nwsol]

@ITCMPHC wrote:

Eventually we unchecked the "Block unsupported cipher suites" in the decryption policy in hopes of allowing these sites to still work but just not be decrypted. Unfortunately in 6.x, this setting appears to be bugged and the site still won't load.

---

Same here. We also configured that setting that way, just to find out it doesn't do anything. Also we have lots of issues with decryption that randomly stops working. Without anything showing in whatever log is reachable from outside.

We opened cases in the beginning, but you start giving up after hearing "they can't find anything" for the 5th time or so.

We are busy upgrading to 7.0.2 hoping to stabilize things, but that hope is fading...

[murphyj]

On top of that there is issues with the decryption profile if you check the Block Sessions with untrusted issuers, the website might not send the full cert chain so the PA will set the site as untrusted instead of doing a quick call and you will have to add the certificate into the PA to not get the Certificate error.

[mikand]

"the website might not send the full cert chain" but that sounds more like a serveradmin error rather than firewall error.

[gwesley]

I'd say the future looks bright!  From the 7.1 New Features Guide:

Decryption support for ephemeral Diffie-Hellman (DHE)-based PFS and elliptic curve Diffie-Hellman (ECDHE)-based PFS is enabled by default when you upgrade a firewall to PAN-OS 7.1 for sessions decrypted with the SSL Forward Proxy decryption method.

[scottsander]

---

@mikand wrote:

"the website might not send the full cert chain" but that sounds more like a serveradmin error rather than firewall error.

---

That's exactly right.  It's a web server admin (or load balancer admin) issue.  But that doesn't help when you have a site that's completely inaccessible in your environment because the remote site's administrators didn't install the intermediate certificate.  You can try talking to their administrators to get them to fix the problem, but that's a big burden*.  You can install the certificate chain in your PAN-OS or exclude the site from decryption, but that's just masking the underlying problem.

* See my topic about blocking sessions with untrusted issuers: https://live.paloaltonetworks.com/t5/General-Topics/SSL-decryption-How-to-deal-with-third-party-site...