- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
01-13-2020 02:48 AM
Hi paloalto community,
we're currently still testing ssl decryption and discovered a new error, which I can't google to find a solution.
If we're visiting the following site, we get an "ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY" error. Site: https://www.1erforum.de/
See attached our configuration and ssl information without decryption enabled.
Firmware and Specs:
PA 850 - FW 9.0.5
Settings:
Decryption disabled:
Decryption enabled:
04-14-2020 12:50 PM
Struggling with this as well. Found that ticking Strip ALPN on the Decryption profile helps, but doing so breaks the Safe Search functionality. When a single safe search block occurs, all traffic begins to be safe search blocked.
05-07-2020 06:51 PM
Solution for
05-08-2020 12:36 AM
Same issue on PA-850 with FW 9.1.2-h1
Tested with https://microsoft.com
I tried the workaround (Objects - Decryption - Decryption Profile - ENABLE/CHECK 'Strip ALPN')
successfully!
BUT to disable HTTP/2 inspection wouldn't/shouldn't be the solution I think. In future HTTP/2 sites will increase - so Palo Alto should get a solution in the software.
Palo - is there any roadmap when this issue is solved without workaround?
06-06-2020 05:11 PM - edited 06-06-2020 05:14 PM
Why is it causing an issue ?
Would be better if there was some (even any ) decrypt logs.
I spend sooo much time trying to guess why a decrypt didn't work
whats is the down side to disabling this ?
09-09-2020 12:48 AM
Has this been resolved or any other investigation done? We are seeing the same issue while using Chrome. The impacted website is https://myesi.esi-group.com/.
09-09-2020 07:23 AM
Hi,
We are also getting impacted by this:
monitoring.solaredge.com/
09-09-2020 02:17 PM
I don't know if it's the same event, but I've previously received the following response from Palo Alto support, so I'll just state it as it is I have not checked this way to see if the sites noted will be able to connect, and I have downgraded and used HTTP/2 by disabling ALPN. Therefore, if you have implemented the following solution, I would be happy to let you know here.
===
When a Client Hello is sent from the client, PANOS receives this Client Hello and sends it to
Send to the web server.
When PANOS sends the Client Hello, it inserts a Cipher Suite, depending on the settings in the decryption profile, and sends it to the WEB server.
The web server receives the Client Hello sent by PANOS and inserts the
Responds to Cipher Suite in the order in which it is presented, with the Cipher Suite supported by the web server.
However, it should have responded with the highest-strength Cipher Suite.
Because the web server responded in the order in which the Cipher Suite was presented, RFC 7540 for HTTP/2
"9.2.2. TLS 1.2 Cipher Suites" used a low strength Cipher Suite that should not be used.
As a result, we received a Server Hello sent from the web server and the client received a FIN
The packet was sent and the traffic was terminated.
Therefore, we have determined that it is a server/client browser issue.
Based on the above, we would like to provide two solutions:
1. In the decryption profile settings, please try to use Cipher Suite (registered in RFC 7040)
Exclude "Appendix A. TLS 1.2 Cipher Suite Black List"
2. use PANOS 10 or higher
(In PANOS 10.0, the order in which Cipher Suite is presented has been changed.)
09-09-2020 02:33 PM
Definitely seems like they have done a whole lot of ssl decrypt work in 10.x.
Pity they will not be back porting into 9.0.
Just have to wait till TAC recommends 10
09-09-2020 03:55 PM
So it's bad enough that the web server chooses a weak Cipher Suite that is not supported by HTTP/2, but don't think paloalto should also backport to PANOS 9.x as soon as possible, because they have solution for their product. There are probably other HTTP/2-related problems, so users who give up and downgrade HTTP/2 are not getting the benefit of HTTP/2 for SSL decryption.
So I think everyone who is affected should contact the TAC for this and raise a request for improvement. I think if paloalto can get a lot of user feedback, their priority will be higher.
Of course, getting people to "like" these comments might help somewhat, too.
09-09-2020 10:35 PM
So basically it seems that the only solution for this is limit the decryption my excluding ECDHE from Key Exchange Algorithms or enabling Strip ALPN. I definitely hope that PA will consider putting this change from 10.x.x also back to 9.x.x.
Can anybody confirm exclusion of ECDHE or ALPN stripping had solve this issue for them?
09-11-2020 06:02 AM
We have ended up with an EDL where we place the URLs that produce the likes of Chrome's
09-23-2020 09:34 AM
Could you share how you have the EDL configured?
11-27-2020 01:45 AM
we ran into this issue too so following with curiousity
12-02-2020 06:21 AM - edited 12-02-2020 06:26 AM
same problem. strip alpn fixes. Chrome is leading browser. How can palo not have noticed this?
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!