Broken SSL Inbound Inspection After July Windows Updates Enables TLS 1.3

[fhewiufhwefhwe]

I have been using SSL Inbound Decryption for over a year with options

1) Block sessions with unsupported versions

2) Block sessions with unsupported cipher suites

After applying Windows 10 updates to a reverse proxy server, it appears that connection to website is encrypted and authenticated using TLS 1.3, X25519, and AES_256_GCM (based on Google Chrome developer tools security tab). 

I now get the error SSL_ERROR_NO_CYPHER_OVERLAP.  This error goes away only if I disable 2) Block sessions with unsupported cipher suites from the SSL Inbound Decryption policy.  Permitting all the cipher suites in the decryption profile without disabling #2 does not work.  Does Palo Alto support Inbound SSL decryption for TLS 1.3 for any PanOS?

Has anyone resolved a similar issue update windows registry keys to force the connection to use TLS 1.2?

[Remo]

Hi @fhewiufhwefhwe 

Decryption of TLS 1.3 is supported in PAN-OS 10 (but I definately do not recommend to install this just released PAN-OS version in a production environment).

So the other way is to diable TLS1.3 untill PAN-OS 10 becomed a prefered release by PaloAlto TAC Support. So far I was not able to find anything related to disable TLS1.3 but I assume it should work the same way as you can disable older versions like TLS1.0/TLS1.1: https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings#tls-11

[fhewiufhwefhwe]

I tried disabling TLS 1.3 on the reverse proxy server with the HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL registry keys, but wasn't able to get the webpages to load.

I have been able to get it to load by either turning off ssl inbound decryption, or rolling back a critical windows update.   I'm doing the former now.

[Remo]

I assume you did reboot the system after the TLS1.3 deactivation?

Btw. did you install an insider preview build? I was only able to find information about TLS1.3 activation in such preview builds...

[fhewiufhwefhwe]

No, it is not a preview release.  The reverse proxy server is using Windows 10 Pro.  I had the problem both with and without installing the May 2020 feature pack.

[Remo]

What software do you use exactly for the reverse proxy part?

[fhewiufhwefhwe]

IIS

[Remo]

Hmn ... strange ... (I want to have TLS1.3 on my IIS too but something obviously I am doing wrong 😛 )

Anyway, back to the actual issue:

• Did you try to do a packet capture of the full connection? Traffic between the client and the firewall and also between the firewall and the iis? In this capture you should see the TLS handshake packets including the ciphersuite proposal
• Did you do a packet capture when you connect from a client either directly to the reverse proxy or then with the unsupported protocol/algorithm checkbox disabled?
• Compare the TLS handshakes in the packet captures if there are differences

If not done already maybe you should consider doing these captures and maybe post the results here.

[fhewiufhwefhwe]

No, I will look into a packet capture.  I did configure a restricted vpn as a temporary workaround for a 3rd party whose access was broken.

[fhewiufhwefhwe]

Monitor->Traffic->Logs shows 

session end reason = decrypt-unsupport-param

from zone = trust

to zone = DMZ

source = client

destination = public ipaddress for website hosted on DMZ

NAT applied

Wireshark 3.2.4 packet capture from client to public ipaddress for website hosted on DMZ

For purposes of testing, both the reverse proxy server and the client have the following windows registry key settings.  I'll review and disable weak ciphers once SSL Inbound Inspection works again...

HKLM\System\ControlSet001\Control\Cryptography\Configuration\Local\SSL\00010002\Functions
TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_NULL_SHA
TLS_PSK_WITH_AES_256_GCM_SHA384
TLS_PSK_WITH_AES_128_GCM_SHA256
TLS_PSK_WITH_AES_256_CBC_SHA384
TLS_PSK_WITH_AES_128_CBC_SHA256
TLS_PSK_WITH_NULL_SHA384
TLS_PSK_WITH_NULL_SHA256

[fhewiufhwefhwe]

Confirmed support for TLS 1.3 via a scanning tool

I'll try moving the TLS 1.3 ciphers to the end of the list.

[fhewiufhwefhwe]

I tried upgrading to PanOS 10.0 to see if it would fix the issue, but that also does not work surprisingly.