Decryption Rules Best Practices
This chapter provides an example decryption policy with decryption rules that illustrates our best practices and recommendations. First we'll discuss settings for the decryption policies and access control policies and then walk through all the rules and why we recommend they be ordered in a particular way.
Some general guidelines:
-
Decrypting traffic requires processing and memory; decrypting too much traffic can impact performance. Before you set up decryption policies and rules, see When to Decrypt Traffic, When Not to Decrypt.
-
Among the types of traffic you should exclude from decryption is traffic that is by nature undecryptable; typically, undecryptable traffic uses TLS/SSL certificate pinning. .
Following are the decryption rules we'll discuss in this chapter.
Bypass Inspection with Prefilter and Flow Offload
Prefiltering is the first phase of access control, before the system performs more resource-intensive evaluation. Prefiltering is simple, fast, and early. Prefiltering uses limited outer-header criteria to quickly handle traffic. Compare this to subsequent evaluation, which uses inner headers and has more robust inspection capabilities.
Configure prefiltering to:
-
Improve performance— The sooner you exclude traffic that does not require inspection, the better. You can fastpath or block certain types of plaintext, passthrough tunnels based on their outer encapsulation headers, without inspecting their encapsulated connections. You can also fastpath or block any other connections that benefit from early handling.
-
Tailor deep inspection to encapsulated traffic—You can rezone certain types of tunnels so that you can later handle their encapsulated connections using the same inspection criteria. Rezoning is necessary because after prefiltering, access control uses inner headers.
If you have a Firepower 4100/9300 or Secure Firewall 3100/4200 available, you can use large flow offload, a technique where trusted traffic can bypass the inspection engine for better performance. You can use it, for example, in a data center to transfer server backups.
Do Not Decrypt Best Practices
Log traffic during evaluation period
Do Not Decrypt rules generally should disable logging but if you're not sure what traffic matches your rules, you can temporarily enable logging. After you confirm the correct traffic is being matched, disable logging for those rules.
Guidelines for undecryptable traffic
We can determine that certain traffic is not decryptable either because the website itself is not decryptable or because the website uses TLS/SSL pinning, which effectively prevents users from accessing a decrypted site without errors in their browser.
For more information about certificate pinning, see About TLS/SSL Pinning.
We maintain the list of these sites as follows:
-
A Distinguished Name (DN) group named Cisco-Undecryptable-Sites
-
The pinned certificate or undecryptable application filter
If you are decrypting traffic and you do not want users to see errors in their browsers when going to these sites, we recommend you set up a Do Not Decrypt rule toward the bottom of your decryption rules.
An example of setting up a pinned certificate application filter follows.
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 decryption 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.
Decryption Rules to Put First
Put first any rules that can be matched by the first part of the packet; an example is a rule that references IP addresses (Networks rule condition).
Decryption Rules to Put Last
Rules with the following rule conditions should be ordered immediately be last because those rules require traffic to be examined for the longest amount of time by the system:
-
Applications
-
Category
-
Certificate
-
Distinguished Name (DN)
-
Cert Status
-
Cipher Suite
-
Version
)
)
Feedback