SSL Decryption: ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

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

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. 

Lol i'm having issues with 

https://microsoft.com/

 

sigh !

 

is there a bug id or a work around ?

L2 Linker

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?

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 ?

 

 

L1 Bithead

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

Hi,

 

We are also getting impacted by this:

 

monitoring.solaredge.com/

"Here I am, Send me"

@kalolu 
@TyronF 

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 

ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY error. This EDL in its turn is used in a decryption rule with "Strip ALPN" option ticked in the decryption profile, and that rule is placed above our default decryption rule. Thus we still decrypt all these sites but downgrade them to HTTP1.1 - is not a big deal. We have ~13K web users and so far discovered only a handful of misbehaving websites... running 9.0.x. Hope this helps.

Could you share how you have the EDL configured?

L3 Networker

we ran into this issue too so following with curiousity

same problem.  strip alpn fixes. Chrome is leading browser.   How can palo not have noticed this?   

  • 52006 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!