Inbound SSL decryption

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

Inbound SSL decryption

L3 Networker

I am trying to set up a TLSv1.3 / TLSv1.2 webserver behind a palo firewall with ssl inbound decryption.

However i seem to get a lot of ssl errors and the website does not work if specific ciphers are not listed first...

For one I would like to understand why that is and even ciphers listed here have issues: https://docs.paloaltonetworks.com/compatibility-matrix/supported-cipher-suites/cipher-suites-support...

 

Basically, what should the apache config look like for the palo to be able to decrypt the traffic, yet still have the highest possible security (e.g. as rated by https://www.ssllabs.com/ssltest/) ?

1 accepted solution

Accepted Solutions

That wont fully work with TLSv1.2 and TLSv1.3 at the same time, I figured out how to do this a while back and gave an example config to TAC but here it is as reference for everyone...

To support both TLSv1.2 and TLSv1.3 at the same time and use secure ciphers, I found the following to work the best:

Apache:

 

Spoiler

SSLOpenSSLConfCmd ECDHParameters brainpoolP256r1

SSLOpenSSLConfCmd Curves secp521r1:secp384r1:prime256v1
SSLOpenSSLConfCmd SignatureAlgorithms ECDSA+SHA512:ECDSA+SHA384:ECDSA+SHA256:RSA+SHA512:RSA+SHA384:RSA+SHA256:rsa_pss_rsae_sha512:rsa_pss_rsae_sha256

SSLCipherSuite "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384"

 

nginx:

 

Spoiler

ssl_conf_command ECDHParameters brainpoolP256r1

ssl_conf_command Curves secp521r1:secp384r1:prime256v1
ssl_conf_command SignatureAlgorithms ECDSA+SHA512:ECDSA+SHA384:ECDSA+SHA256:RSA+SHA512:RSA+SHA384:RSA+SHA256:rsa_pss_rsae_sha512:rsa_pss_rsae_sha256

ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384

this needs a certain minimum version of openssl and apache/nginx 🙂

a bit cumbersome but oh well...

it fulfills palos restrictions/requirements while still offering all compatible and secure ciphers and being compatible to modern browsers (I checked this for TLSv1.2 and TLSv1.3 only as those were the only secure ones).
if anyone does the same in other flavors like lighttpd, haproxy or any other platform that might need customization, please be so kind and post an example here as well so others can adapt it into their configs 🙂

View solution in original post

9 REPLIES 9

L2 Linker

Hi,

 

which PANOS version are you running? Some logs might be helpful as well.

 

Thanks.

 

 

 

 

Kind regards,
René
// If you like my answer force commit it.

running PANOS 10.0.1, log only shows "General TLS protocol error" together with the ciphers that were used

any specific debug or log i should show?

@Rene_Boehme or anyone know working ciphers for apache with TLSv1.2 and which ones work TLSv1.3?

There is nothing in the sslmgr.log and nothing but the General errors in the UI

the only ciphers that seem to work with Palo decryption on TLSv1.2 and Chrome/Firefox are these two:

AES256-GCM-SHA384:AES128-GCM-SHA256

all others error out even if those ciphers above are also available but not listed first (SSLHonorCipherOrder is set to off)

but with these ciphers which are considered weak, i dont even get forward secrecy and therefore the rating is down to B...

I wonder why the following ciphers dont work:
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHCHA20-POLY1305-SHA256:CHACHA20-POLY1305-SHA256 or the ECDHE-ECDSA ones which are listed as supported but not shown in the decryption profile settings

 

anyone have an idea or even just an idea how to troubleshoot this further?

from a wireshark capture, i can see that if for TLSv1.2 any other supported protocols are used, the palo sens a Server Hello with the first matching cipher and right after it sends a [RST, ACK] to the client which is originated only from the firewall, the server actually sends the certificate to the palo, so the issue seems to be between the palo and the client with PANOS 10.0.1

 

I should probably open a support case to look into this but I thought maybe someone has already looked into this 🙂

I am seeing the same issue on 10.0.6.  I've already removed EC X25519 on the web server and I can see it sends secp521r1 in the key exchange but still the Palo sends a RST to the client.  I see the following global counter increases related to the problem and find it odd the Palo is always showing client is requesting TLSv1.3 when I can see in the PCAP from the Palo the client is only supporting up to 1.2.

 

proxy_tls13_client_hello 1 0 info proxy pktproc TLS13: tls1.3 client hello received
proxy_tls13_inbound_no_server_support 1 0 info proxy pktproc TLS13: Server doesn't support tls1.3
ssl_unsupported_server_extension 2 0 warn ssl pktproc Number of unsupported ssl ext in server hello

L0 Member

What was the solution for this we are seeing the same thing with version 10.0.8-h4, selected cipher is ECDHE_RSA_WITH_AES_256_GCM_SHA384 and PA seems to be causing error due to this.

I'm running 10.0.9 and decryption is working with cipher ECDHE_RSA_WITH_AES_256_GCM_SHA384.  The problem I ran into was with clients using NSS or Schannel for TLS where the client included pss signature hash algorithms.  More info in this link about Palo supported signature algorithms.  https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000PMaTCAW

 

I use the following two commands in apache ssl configuration to disable the x25519 curve ( not supported by PanoOS in tlsv1.2 ) and setting the signature algorithms supported by the server.

 

SSLOpenSSLConfCmd Curves secp521r1:secp384r1:prime256v1
SSLOpenSSLConfCmd SignatureAlgorithms ECDSA+SHA512:ECDSA+SHA256:RSA+SHA512:RSA+SHA256

That wont fully work with TLSv1.2 and TLSv1.3 at the same time, I figured out how to do this a while back and gave an example config to TAC but here it is as reference for everyone...

To support both TLSv1.2 and TLSv1.3 at the same time and use secure ciphers, I found the following to work the best:

Apache:

 

Spoiler

SSLOpenSSLConfCmd ECDHParameters brainpoolP256r1

SSLOpenSSLConfCmd Curves secp521r1:secp384r1:prime256v1
SSLOpenSSLConfCmd SignatureAlgorithms ECDSA+SHA512:ECDSA+SHA384:ECDSA+SHA256:RSA+SHA512:RSA+SHA384:RSA+SHA256:rsa_pss_rsae_sha512:rsa_pss_rsae_sha256

SSLCipherSuite "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384"

 

nginx:

 

Spoiler

ssl_conf_command ECDHParameters brainpoolP256r1

ssl_conf_command Curves secp521r1:secp384r1:prime256v1
ssl_conf_command SignatureAlgorithms ECDSA+SHA512:ECDSA+SHA384:ECDSA+SHA256:RSA+SHA512:RSA+SHA384:RSA+SHA256:rsa_pss_rsae_sha512:rsa_pss_rsae_sha256

ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384

this needs a certain minimum version of openssl and apache/nginx 🙂

a bit cumbersome but oh well...

it fulfills palos restrictions/requirements while still offering all compatible and secure ciphers and being compatible to modern browsers (I checked this for TLSv1.2 and TLSv1.3 only as those were the only secure ones).
if anyone does the same in other flavors like lighttpd, haproxy or any other platform that might need customization, please be so kind and post an example here as well so others can adapt it into their configs 🙂

  • 1 accepted solution
  • 11704 Views
  • 9 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!