How to Identify Root Cause for SSL Decryption Failure Issues

Printer Friendly Page

Overview

This document provides instructions on how to identify decryption failures due to an unsupported cipher suite.

 

Check out the following compatibility matrix to confirm the currently supported cipher suites :

Supported Cipher Suites

 

Issue

In this example, the SSL proxy decryption fails because the server only supports Diffie-Hellman (DH) and Elliptec Curve Ephemeral Diffie-Hellman (ECDHE).

Follow these steps to confirm the issue:

 

  1. Run a packet capture from the Palo Alto Networks device (see How to Run a Packet Capture). Examine Client Hello packets sent by the client and the response packets sent by the server. Look for "Handshake Failure," which is shown below.
    step-1.PNG
  2. View the Cipher Suites supported by the client or Palo Alto Networks device in the Client Hello packets.
    step-2.PNG
  3. Using the SSL scan tool https://www.ssllabs.com/ssltest/index.html, find out which cipher suites are supported by the server. See this example:
    Step-3.PNG

The output above confirms that the issue is due to unsupported cipher suites.

 

Resolution

Create a No Decrypt policy.

  1. Create a Custom URL Category for that site.
    1. Go to > Objects > URL Category.
    2. Click on the Add button.
    3. Name the Custom URL Category.
    4. Click the Add button and then add the server's site and commit.
      WA1.PNG
  2. Create a Decryption Policy with a No Decrypt action of that URL site.
    1. Go to Policies > Decryption.
    2. Select the Decryption Rule.
    3. Clone the Decryption Rule.
    4. Move the Clone Decryption Policy above the Decryption Policy.
    5. Click on the Clone Decryption Policy > URL Category.
    6. Click on the Add button.
    7. Add the URL site and commit.
      WA2.PNG

 

owner: ssastera

Comments

What happens if let's say the servers upports ECDHE or DH but also the PA supported protocols as fallback. I assume ECDHE/DH are usually preferred. Is there a way to force the internal client to still use let's say TLS_RSA_WITH_AES_256_CBC_SHA instead of ECDHE/DH?


Thanks, Oliver

Oliver,

The server and client will negotiate the strongest that they both support.  Therefore, if they negotiate DH or ECDH we won't be able to decrypt it.  It is recommended to only have the cipher suites that we support turned on so that nothing unsupported can get negotiated.

As of mid 2015 I'm finding more and more sites using only a limited number of ciphers, none which match what the Palo Alto Firewall supports.  This results in SSL setup failure.

Please add support for some of these additional ciphers.  

With regards to forward decryption, couldn't the Palo Alto firewall's SSL/TLS negotiation to a webserver support additional ciphers while using a different set of cipher when talking to the PC on my network?   In other words, couldn't the Palo Alto firewall negotiate TLS 1.2 with forward secrecy to webserver that support this, while communicating with my legacy XPSP3 stations on my secured network with TLS1.0 and the one decent cipher LS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x13) , or if the machine doesn't have the patch that adds that cipher, TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa).

Edwin

That would be a nice feature. Please count me +1 on the wish list :-)

Thanks eroberts. Would it help if we changed the cipher priorities on our clients using GPOs to prefer the PA supported protocols but still allow the negotiation of ECDHE or DH if the server supports only those?

We are using the PA mainly for Security our clients against the internet - therefore we use SSL-Decryption a lot. Unfortunately (for us), more and more sites choose to use strong ciphers with or without Forward Secrecy.

When will PA be able to decrypt these suites? This is a very important feature for us.

And another idea: is it possible to create a message-page (like a portal-page) explaining to the customer when this happens? In our setup the PA sits between the clients and our proxy. If the decryption fails, the connection just gets closed but the customer has no idea why. If there would be a possibility to give an error-page, that would be helpful.

it_sicherheit I haven't tested this myself but there's a "SSL Certificate Errors Notify Page" under "Device \ Response Pages" . Maybe that's what you're looking for...

All of my customers having problems with unsupported ciphers. 

It is unexplainable for me why PA does not support a wider ranges of cipher suites.

 

Besides that it is a shame that the user will get absolutely no feedback when the PA is not able to decrypt including the reason why (only a connection reset) (@oschuler: your mentioned response page will be displayed for revoked(!) certificates only - according to the documentation).

 

Those both things above (small number of supported cipher suites + no response page) makes the SSL decryption not usable at the moment and I can't believe that this is so ignored by PA.

We excluded N number of website from decryption because of unsupported ciphers. What if we want to inspect content/file of that particular website; what will be the solution ?

We tried by using purchased cert which was signed by go daddy for our organization, but tac person told us that we can't use certificate provided by some CA's like go daddy in ssl forward proxy as go daddy not provide private key for the CA cert.

And that's true also.



Hi @Deepak_Khirit,

 

Unfortunately not all sites can be decrypted (unsupported ciphers, certificate pinning, ...).  As such, deep inspection on those websites might not possible at all.  Make sure that you have the latest PAN-OS version so that the most possible cipher suites are supported.  If decryption is still not possible on certain sites and you are worried about some vulnerability coming in via those channels then I recommend installing TRAPS as an endpoint solution for the extra layer of defense.

 

Cheers !

-Kiwi.