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. "
Here is the current decryption profile for reference
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:
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:
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)
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.
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!