IE doesn't care if you are using a weak cipher suite, which is why it's working in IE but not Firefox or Chrome. The bigger issue is why the decryption process isn't negotiating to the strongest available cipher unless the site has been configured with a cipher preference that makes it utilize the strongest cipher suites by default (such as Chrome). It appears through additional troubleshooting that the firewall is using the first matching cipher, which in the case of these example sites isn't strong enough to meet the requirements of the browser.
In fairness to PAN, the HTTP/2 connection shouldn't be attempting to use a questionable cipher suite such as in the di.fm example. The vast majority of the HTTP/2 enabled websites will work perfectly fine, because the site owner is specifying the preferred order with strong to weak ciphers. In the examples listed so far the server is providing no preference order, which could be causing the firewall to negotiate to one of the weaker cipher suites being offered by the server.
Sounds like a feature which the PA team should consider? For my point of view it's more like a bug. If browsers can view the page, the PA should do it too.
For our users the current state is very bad - they will assume the page (e.g. of a customer) is not working, but instdead we have to whitelist it to exclude it from decryption.
same issue applies for us (PANOS 9.0.5 & 9.0.6, incl. Prisma Access) and a solution would be very appreciated.
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!