SSL Decryption: ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

SSL Decryption: ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY

L1 Bithead

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:

2020-01-13 11_42_30-pa-1.png2020-01-13 11_42_39-pa-1.png

 

Decryption disabled:

2020-01-13 11_42_56-Anhängerkupplung M240i _ M140i.png

 

Decryption enabled:

2020-01-13 11_46_30-www.1erforum.de.png

36 REPLIES 36

Same issue for us also ....

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

L1 Bithead

Same issue here with this URL

 

https://svp.protectionone.de/ 

 

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

L4 Transporter

Solutions anyone?  Other than strip alpn?

So far ... no

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:

Screenshot_20210723-220150_Chrome.jpg

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:

Screenshot_20210723-222613_Chrome.jpg

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 ...

 

L0 Member

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

Not exhaustively tested but works so far!

 

AlexChard_0-1627430309560.png

 

  • 46701 Views
  • 36 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your 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!