Decrypt-error with Inbound Decryption DHE or ECDHE on 8.1.3

Reply
L4 Transporter

Re: Decrypt-error with Inbound Decryption DHE or ECDHE on 8.1.3

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

Tags (2)
L7 Applicator

Re: Decrypt-error with Inbound Decryption DHE or ECDHE on 8.1.3

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.

L4 Transporter

Re: Decrypt-error with Inbound Decryption DHE or ECDHE on 8.1.3

@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.

L4 Transporter

Re: Decrypt-error with Inbound Decryption DHE or ECDHE on 8.1.3

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.

L7 Applicator

Re: Decrypt-error with Inbound Decryption DHE or ECDHE on 8.1.3

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.

L0 Member

Re: Decrypt-error with Inbound Decryption DHE or ECDHE on 8.1.3

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

L1 Bithead

Re: Decrypt-error with Inbound Decryption DHE or ECDHE on 8.1.3

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.

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 Live Community as a whole!

The Live Community thanks you for your participation!