Decrypt - Resign and Decrypt - Known Key Best Practices

This topic discusses best practices for Decrypt - Resign and Decrypt - Known Key decryption rule.

Do not use Version or Cipher Suite rule conditions

Important

Never use either Cipher Suite or Version rule conditions in a rule with a Decrypt - Resign or Decrypt - Known Key rule action. The use of these conditions in rules with other rule actions can interfere with the system's ClientHello processing, resulting in unpredictable performance.

Decrypt - Resign best practices with certificate pinning

Some applications use a technique referred to as TLS/SSL pinning or certificate pinning, which embeds the fingerprint of the original server certificate in the application itself. As a result, if you configured a decryption rule with a Decrypt - Resign action, when the application receives a resigned certificate from a managed device, validation fails and the connection is aborted.

Because TLS/SSL pinning is used to avoid man-in-the-middle attacks, there is no way to prevent or work around it. We recommend adding a Do Not Decrypt rule before the Decrypt - Resign rule so pinning traffic is excluded from being decrypted.

For more information about certificate pinning, see About TLS/SSL Pinning.

Decrypt - Known Key best practices

Because a Decrypt - Known Key rule action is intended to be used for traffic going to an internal server, you should always add either a destination network to the TBD rule rules (Networks rule condition) or add a security zone to the access control rule (Zones tab page). That way the traffic goes directly to the network or interface on which the server is located, thereby reducing traffic on the network.