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.)
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
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.
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?
We have ended up with an EDL where we place the URLs that produce the likes of Chrome's
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!