ssl inbound inspection

Abdul_Razaq · ‎01-15-2019

Hi community,

Will PA support inbound ispection if key exchnge mechanism is DHE/ECDHE ?.

i hope PA wont be proxying inbound SSL connection. whether PA changed this behaviour from any versions?

is there is a way to configure PA as proxy( we have server certificate/key installed in PA, only issue is PA resources. So if my website traffic is usually less, will i able to do proxying ?)

what if i need to do inbound decryption for servers using DHE ?

is it nessossary to change the behaviour in server that to use only RSA as key exchange ?

Abdul_Razaq · ‎02-06-2019

Hi @gwesson , Thanks.

I found the issue, as i was running PanOS 8.0.13, PA should be doing proxy,

The issue was, the web server was on windows 2016 and the default elliptic curve it was using was 25519, which i hope currently not supported by PA. post disabling/changing priority of curve, i am able to do inbound inspection successfully.

View solution in original post

gwesson · ‎01-15-2019

Starting with PAN-OS 8.0, it supports inbound with DHE/ECDHE. See this in the new features guide: 8.0 Inbound PFS

It is proxying the TLS traffic. That is the only way to decrypt DHE/ECDHE, since (by design of the exchange mechanism) it cannot be decrypted passively even with the private key.

Abdul_Razaq · ‎01-15-2019

Thanks gwesson
I am running 8.0.13 in my device, still i am getting decryption error. If PA is working as proxy, we should not get any unsupported parameter error as PA will be involved in selecting ciphersuit. I feel PA still trying to do decryption passively as i am getting parameter error, which contradicting PA document. do i need to enable it anywere? (i already selected all options in ssl protocole section). I understand if DHE is the key exchange, PA wont be able to see key as key is not shared as such, but end systems generate it with value exchange and math operations, PA should be proxy in this situation which is there in doc. Do i have an option to manually enable proxying?

gwesson · ‎01-15-2019

> If PA is working as proxy, we should not get any unsupported parameter error as PA will be involved in selecting ciphersuit.

Not quite right. The firewall supports a specific subset of ciphers, and if your client is only presenting non-matching ciphers you'll fail to establish the connection. The full list is here, with the ECDHE and DHE on the bottom:

https://docs.paloaltonetworks.com/compatibility-matrix/supported-cipher-suites/cipher-suites-support...

You don't need to manually enable proxying, it's always a proxy. Starting in 8.0, both inbound and outbound is acting as a proxy.

I didn't see any specific error message in your original post, so I don't know what "parameter error" you're referring to, but the ciphers is typically the easiest to confirm.

If your site is public, you can use Qualys SSL scaner or even nmap to see what ciphers are supported.

Abdul_Razaq · ‎01-15-2019

Hi gwesson, appreciate your kind support.

without inbound decryption, client and server was aggying on TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, which is supported in PanOS 8.0 ,

i am able to brows the website if i do a forward proxy( configured forward proxy from one internet ip to webserver for testing eventhough it is not the use of forward proxy), means there is atleast one matching ciphersuit in between client-PA and PA-server.

So i feel if PA was doing a inbound as a proxy as in the document, i wont face any issue. is there any known bug or something, which solved in later versions ?

The following is the error PA sends to both server and client once he recieves server hello packet,

TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Length: 2
Alert Message
Level: Fatal (2)
Description: Handshake Failure (40)

gwesson · ‎01-16-2019

A handshake failure is unfortunately very generic and doesn't explain *why* there was an error, just that there *was* an error. It's the nature of the encryption so there's not much you can typically learn from just that.

You'll likely want to open a support ticket, as there may be more troubleshooting steps that can fork depending on some results. Generally, the times I see a handshake failure are:

- An unsupported cipher

- A blocked cipher (via the Decryption Profile)

- The server requires client certificate authentication

But beyond those three, you'll probably want some official support in troubleshooting it.

Abdul_Razaq · ‎01-17-2019

Thank gwesdon,
I really appreciate your help. I feel i am having little confution at how decryption profile works,
-what if PA finds that client and server agrees on a ciphersuit PA doest support, PA will put it no decrypt or block session ?(i didnt checke 'block unsupported ciphersuit' under ssl inbound.
-in my case if i select only 'DHE' in key echange, communication happens properly( i am not selected any blocking options under decryption profile inbound inspection) , is PA is actually decryptiong traffic?. Because in same profile if i just check 'block unsupported ciphersuit', communication fails. Which makes me feel like PA wont support on agreeying ciphersuit, and if that is the case PA wont be able to proxy and decrypt no?(but in Traffic field it shows decrypted), makes bit confusion about how this works.

Abdul_Razaq · ‎01-21-2019

Added to above all,

i found that server was sending hello packet with 'Master Secret Extension', 'ALPN' extentions enabled, upon checking some document, i am seeing 'Master Secret Extension' may cause decryption to break if proxied. is it the issue i am hitting on?

is this solved in any of new versions( i am running 8.0.13 currently).

i have seen that PA wont modify the client hello to allowed algorithms configured in decryption profile while i am doing ssl inbound inspection. But it does modify and delete unconfigured ciphersuits for forward proxy.. Is this intended behaviur ?..or is it a bug or MITM cannot modify hello if he is not doing proxy?.

Thanks in advance.

Abdul_Razaq · ‎02-06-2019

Hi @gwesson , Thanks.

I found the issue, as i was running PanOS 8.0.13, PA should be doing proxy,

The issue was, the web server was on windows 2016 and the default elliptic curve it was using was 25519, which i hope currently not supported by PA. post disabling/changing priority of curve, i am able to do inbound inspection successfully.

1LinkNetwork · ‎04-09-2020

I am also facing SSL in bound decryption error . In Packet capture ''named Curve : x25519 is showing . When i have asked with Server team they are using default cipher suit in their windows server 2016 . Its mean default setting is using 25519 curve ? its need to be disabled from server end ?

Right now any work around in Palo alto ?