Decrypt-error with Inbound Decryption DHE or ECDHE on 8.1.3
cancel
Showing results for 
Search instead for 
Did you mean: 

Decrypt-error with Inbound Decryption DHE or ECDHE on 8.1.3

L4 Transporter

Greetings all,

 

I feel like I'm probably missing something simple here, but I'm running into a decrypt-error issue on 8.1.3 in regards to a server that is negotiating DHE or ECDHE ciphers with the client.  On Chrome I get:

 

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

 

And on Firefox I get:

 

SSL_ERROR_NO_CYPHER_OVERLAP

 

If I turn off decryption for this or set it to RSA only, the traffic goes through (albeit not decrypted) so the client and server do indeed have shared ciphers they can negotiate to.  A packet capture from my machine and an SSL Labs scan of the server seems to back this up.

 

I know DHE and ECDHE wasn't supported on Inbound Decryption before but the warning is no longer on the configuration GUI and I see newer documentation that it has been supported since an 8.0 version.

 

Any ideas on what I might be doing wrong or how I should proceed with troubleshooting?

17 REPLIES 17

I found the SSL Labs IP range.  Some of the traffic does appear to be decrypted while some of it hits a decrypt-error.

 

I also see "This server's certificate chain is incomplete. Grade capped to B. "

 

ssllabs1.png

 

 

ssllabs2.png

 

Here is the current decryption profile for reference

 

object.png

The chain warning just means that the server (firewall in this case) isn't sending the intermediate CAs. It's not usually a problem and will not cause the issue you're seeing, but also has a way to totally eliminate it. Here's an article I wrote that goes into the details:

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClkoCAC

 

As for the handshake_failure warnings seen, those are the real problem. That the Qualys scan shows it failing Chrome 69 and 70 echoes what you see. 

 

I can tell you that the firewall is the one causing this, but whether it's configuration or something else would probably need to be investigated further using the firewall logs and some debugs. I won't suggest that here, it's too dangerous to do unless you're very familiar with the debugging process for proxy-based decryption. 

 

I would recommend opening a support ticket, and would suggest pointing the engineer who gets your ticket to this thread as well.

@gwessonnot sure how I missed that with the Intermediary cert but thanks!  I had it uploaded for on Panorama but not in the Device Group that pushed to the firewall... I added it and it immediately changed the Wildcard to be a sub-cert.  I did another scan and it hows correct now.

 

I'm opening a TAC case for the SSL decryption issue and I'll reply again when I have a solution in case someone else runs into this as well.

So an update.. it was determined the server and client are trying to use X25519 which is an ECDHE curve that Palo Alto doesn't support (definitely would be nice to see this as a note on the supported ciphers page... TLSv1.3 uses it as a standard and I know that isn't supported yet but TLSv1.2 uses it as well).

 

The workaround is to disable ECDHE but that doesn't seem like a great call given that we're talking about lowering server security to apply SSL Decryption for additional server security.

 

I found this for Windows Server 2016 and it seems to work:

https://www.nsgp.net/2018/09/how-to-disable-curve25519-x25519-key-exchange-on-windows-server-2016/

 

I'm looking for similar instructions for Apache and Tomcat.  I'm not a server expert and I'm having trouble finding methods to do this on those platforms.

With my (limited) Apache knowledge, you don't strictly exclude specific curves but rather include only the ones you want. You would put a line in your httpd.conf (or apache.conf, or whatever your site uses). It will probably wrap when I post this, but it will all be on one line. I stole this from Apache Lounge:

 

SSLOpenSSLConfCmd Curves sect571r1:sect571k1:secp521r1:sect409k1:sect409r1:secp384r1:sect283k1:sect2... 

 

You can also use the SSLCipherSuite directive to exclude entire suites as needed.

Did you get any further? I am struggling with  similar issue and have been debugging for two days now getting further and further. In case of Apache I can say there seems to be a lot of requirements to get decryption  working on latest version 2.4.39 (which i haven't managed to get fully working yet) 

 

Benjamin

Very disappointing that I cannot use Palo for SSL inspection any more due to our load balancer AVI, is using OpenSSL v1.1.1 which defaults to X25519 curve for ECDEH and DHE PFS ciphers using TLS1.2/1.1 so the only option I have is to use the RSA-AES-256-GCM or CBC ciphers which then caps you SSL security rating to B vs A+ with ECDHE ciphers.

 

Come on Palo, fix the issue and support the curve x25519, you need that curve for TLS1.3 support.

L2 Linker

You will need to feature request that...
For Apache and nginx this requires a specific configuration and order (actually x25519 does not seem to be needed for tls1.3 but rsa_pss signature algorithm is and that is also not supported for tls1.2) to work... but it does work!
So if you do feature request this with your SE, make sure you also request support for rsa_pss signature algorithm

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!