SSL Decryption: ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY

[mrkskhn]

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:

[user1234]

Same issue for us also ....

[dwharam]

This is what we also did.  So far, just a handful of sites.  As somebody else pointed out, this article is helpful https://tools.ietf.org/html/rfc7540

[Kuhn_Andreas]

Same issue here with this URL

https://svp.protectionone.de/ 

PA 220 and 3220 with PanOS 9.1.8 ... any solution ???

[Sec101]

Solutions anyone?  Other than strip alpn?

[Remo]

So far ... no

[Remo]

For quick tls checks I often use https://www.ssllabs.com/ssltest/ .

So far I have seen the error in this topic only with servers that do not have a preference with the configured ciphersuites - like this webserver https://svp.protectionone.de/ . The tls 1.2 ciphersuites look like this on ssllabs:

So as far as I know when a browser connects directly to such a webserver it chooses the strongest ciphersuites. When paloalto connects to this webserver with tls1.2 (as 9.1 does not support tls1.3) I assume the order of ciphersuites that the firewall sends to the server is not "correct" for h/2. This means that the order in the client hello probably has not the stronges ones in the first places but then the first one is chosen from that client hello and this one is one of them which are not allowed for h/2. With servers that have a preference, they almost always prefer the strongest ones so the order in the client hello does not matter and the decryption works properly without this error.

With tls1.3 (supported in PAN-OS 10) the situation changes completely as there weak ciphers aren't even part of the specs. So when viewing again this example webserver, with tls1.3 it supports these ciphersuites:

The server still has no preference for the ciphersuites, but as all 3 of them are allowed for h/2 this isn't an issue when decrypting the connection with PAN-OS 10.

So as far as I see it, the solution would be to change the order of ciphersuites in the client hello and this problem would be gone in PAN-OS 9.1 ...

[Alex-Chard]

I have fixed this for some sites by removing SHA1 from the allowed auth algorithms.

Not exhaustively tested but works so far!