Decryption Rules and Policy Example

This chapter builds on concepts discussed in this guide to provide a specific example of an SSL policy with decryption rules that follow our best practices and recommendations. You should be able to apply this example to your situation, adapting it to the needs of your organization.

In short:

  • For trusted traffic (such as transferring a large compressed server backup), bypass inspection entirely, using prefiltering and flow offload.

  • Put first any decryption rules that can be evaluated quickly, such as those that apply to specific IP addresses.

  • Put last any decryption rules that require processing, Decrypt - Resign, and rules that block unsecure protocol versions and cipher suites.

Decryption Rule Examples

This section provides an example of decryption rule that illustrate our best practices.

See one of the following sections for more information.

Run the Decryption Policy Wizard

This task discusses how to run the decryption policy wizard for outbound traffic protection. This policy has four rules:

  1. Do Not Decrypt rule for distinguished names that are known to be undecryptable, most likely because they use TLS/SSL pinning.

  2. Do Not Decrypt rule for URL categories that we classify as sensitive based on their content (for example, medical and financial).

  3. Do Not Decrypt rule for applications that are known to be undecryptable, most likely because they use TLS/SSL pinning.

  4. Decrypt - Resign rule that uses a certificate authority object named IntCA to decrypt the remainder of the traffic.

You can then edit the rules if you want and also manually add:

  • Decrypt - Resign rules for traffic to monitor and determine whether the traffic should be blocked in the future.

  • Do Not Decrypt rules for other types of traffic

  • Block or Block with Reset rules for bad certificates and unsecure cipher suites.

If you enabled Change Management, you must create and assign a ticket before you can create a decryption policy. Before the decryption policy can be used, the ticket and all associated objects (like certificate authorities) must be approved. For more information, see Creating Change Management Tickets and Policies and Objects that Support Change Management.

Procedure

Step 1

Log in to the Secure Firewall Management Center if you haven't already done so.

Step 2

Click Policies > Access Control > Decryption.

Step 3

Click Create Decryption Policy.

Step 4

Give the decryption policy a Name and optionally a Description.

Step 5

Click the Outbound Protection tab.

Step 6

From the Internal CA list, click the name of an internal certificate authority object or click Create New to upload or generate one.

The following figure shows an example.

When you create a decryption policy using the wizard, you can optionally create a new internal certificate authority object

For more information about creating or uploading an internal certificate authority object, see:

Step 7

(Optional.) To restrict traffic to source and destination networks, click Click to assign networks and ports.

Step 8

Click Next.

Step 9

Complete the wizard as discussed in Decryption Policy Exclusions.

Decryption Policy Exclusions

This task discusses how to exclude certain types of traffic from decryption. We create Do Not Decrypt rules in your decryption policy for these although the rules are initially enabled only for an outbound decryption policy (that is, one that uses the Decrypt - Resign policy action).

Before you begin

You must upload an internal CA certificate for your managed device before you can create a decryption policy that protects outbound connections. You can do this in any of the following ways:

  • Create an internal CA certificate object by going to Objects > Object Management > PKI > Internal CAs and referring to PKI.

  • At the time you create this decryption policy.

Procedure

Step 1

Complete the tasks discussed in:

Step 2

The exclusions page provides the following options. All options are enabled for an outbound protection policy (Decrypt - Resign rule action) and disabled for all other decryption policy actions.

Item

Description

Bypass decryption for sensitive URL categories

Check the box to not decrypt traffic from the indicated categories. Depending on the laws in your area, decryption certain traffic, such as finance or health-related, might be prohibited. Consult an authority in your area for more information.

Click Add to add more categories.

Click Delete (delete icon) to remove categories.

Bypass decryption for undecryptable distinguished names

Check the box to not decrypt traffic when re-signing the certificate is likely to cause the connection to fail. Typically, this behavior is associated with certificate pinning, which is discussed in TLS/SSL Certificate Pinning Guidelines.

The list of undecryptable distinguished names is maintained by Cisco.

Bypass decryption for undecryptable applications

Check the box to not decrypt traffic when re-signing the certificate is likely to cause the connection to fail. Typically, this behavior is associated with certificate pinning, which is discussed in TLS/SSL Certificate Pinning Guidelines.

Undecryptable applications are updated automatically in the Vulnerability Database (VDB). You can find a list of all applications on the Secure Firewall Application Detectors page; the undecryptable tag identifies applications Cisco determines are undecryptable.

The list of undecryptable applications is maintained by Cisco.

The following figure shows default options.

For an outbound decryption policy, you can specify which (if any) types of traffic to exclude from decryption. For example, you can exclude traffic going to sensitive website categories such as finance or health.

For an outbound decryption policy, you can specify which (if any) types of traffic to exclude from decryption. For example, you can exclude traffic going to sensitive website categories such as finance or health.

Step 3

Click Create Policy.

The following figure shows a sample outbound protection policy.

This sample decryption policy has one Decrypt - Resign rule applied to traffic that matches the networks and ports chosen. It decrypts traffic and subsequently re-encrypts it by signing with the internal certificate object you specified. We add Do Not Decrypt rules for traffic you specified to be excluded from decryption.

In the preceding example, the Do Not Decrypt rules corresponding to your choices for rule exclusions are automatically added before the Decrypt - Resign rule. The rule for sensitive URL categories is disabled because, by default, that exclusion is disabled. Had you selected the Bypass decryption for sensitive URL categories check box, the rule would have been enabled.

Step 4

Click Create Policy.

What to do next

First Manual Do Not Decrypt Rule: Specific Traffic

The first decryption rule in the example does not decrypt traffic that goes to an internal network (defined as intranet ). Do Not Decrypt rule actions are matched during ClientHello so they are processed very fast.

This sample rule allows traffic to pass undecrypted if it goes to an internal network.

Note

If you have traffic going from internal DNS servers to internal DNS resolvers (such as Cisco Umbrella Virtual Appliances), you can add Do Not Decrypt rules for them as well. You can even add those to prefiltering policies if the internal DNS servers do their own logging.

However, we strongly recommend you do not use Do Not Decrypt rules or prefiltering for DNS traffic that goes to the internet, such as internet root servers (for example, Microsoft internal DNS resolvers built into Active Directory). In those cases, you should fully inspect the traffic or even consider blocking it.

Rule detail:

In this rule, you specify a previously defined internal network on the Networks tab page. To define the internal network, go to Objects > Object Management > Network.

Next Manual Rule: Decrypt Specific Test Traffic

The next rule is optional in the example; use it to decrypt and monitor limited types of traffic before determining whether or not to allow it on your network.

After you run the decryption policy wizard, edit the policy to add the following rule. Drag it to the second position in the list of rules.

This sample rule decrypts and monitors traffic so you can decide whether or not to allow it on your network.

Rule detail:

Last Manual Decryption Rules: Block or Monitor Certificates and Protocol Versions

The last decryption rules, because they are the most specific and require the most processing, are rules that either monitor or block bad certificates and unsecure protocol versions.

After you run the decryption policy wizard, edit the policy to add the following rules. Drag them to a position before the Decrypt - Resign rule.

These sample rules block traffic with either bad certificates or old TLS/SSL protocol versions.

Rule details:

This sample rule allows certificates that are valid and blocks the rest (for example, invalid certificates).

This sample rule blocks traffic with either the SSL 3.0 or TLS 1.0 protocols.

Example: Decryption Rule to Monitor or Block Certificate Status

The last decryption rules, because they are the most specific and require the most processing, are rules that either monitor or block bad certificates and unsecure protocol versions. The example in this section shows how to monitor or block traffic by certificate status.


Important

Use the Cipher Suite and Version rule conditions only in rules with either the Block or Block with reset rule actions. Do not use Cipher Suite and Version with either Decrypt - Resign or Decrypt - Known Key rule actions. These conditions in rules with other rule actions can interfere with the system's ClientHello processing, resulting in unpredictable performance.

Procedure

Step 1

Log in to the Secure Firewall Management Center if you haven't already done so.

Step 2

Click Policies > Access Control > Decryption.

Step 3

Click Edit (edit icon) next to your decryption policy.

Step 4

Click Edit (edit icon) next to a decryption rule.

Step 5

Click Add Rule.

Step 6

n the Add Rule dialog box, in the Name field, enter a name for the rule.

Step 7

Click Cert Status.

Step 8

For each certificate status, you have the following options:

  • Click Yes to match against the presence of that certificate status.

  • Click No to match against the absence of that certificate status.

  • Click Any to skip the condition when matching the rule. In other words, choosing Any means the rule matches whether the certificate status is present or absent.

Step 9

From the Action list, click either Monitor to only monitor and log traffic that matches the rule or click Block or Block with Reset to block the traffic and optionally reset the connection.

Step 10

To save changes to the rule, at the bottom of the page, click Add.

Step 11

To save changes to the policy, at the top of the page, click Save.

Example

The organization trusts the Verified Authority certificate authority. The organization does not trust the Spammer Authority certificate authority. The system administrator uploads the Verified Authority certificate and an intermediate CA certificate issued by Verified Authority to the system. Because Verified Authority revoked a certificate it previously issued, the system administrator uploads the CRL that Verified Authority provided.

The following figure shows a certificate status rule condition checking for valid certificates, those issued by a Verified Authority, are not on the CRL, and still within the Valid From and Valid To date. Because of the configuration, traffic encrypted with these certificates is not decrypted and inspected with access control.

Example of SSL policy with rule condition that matches valid certificates not in a CRL with valid dates

The following figure shows a certificate status rule condition checking for the absence of a status. In this case, because of the configuration, it matches against traffic encrypted with a certificate that has not expired.

Example of SSL policy with rule conditions that match in the absence of status

In the following example, traffic would match this rule condition if the incoming traffic is using a certificate that has an invalid issuer, is self-signed, expired, and it is an invalid certificate.

The following graphic illustrates a certificate status rule condition that matches if the SNI of the request matches the server name or if the CRL is not valid.

Example of an SSL policy rule matching the server SNI name or invalid CRL

Example: Decryption Rule to Monitor or Block Protocol Versions

This example shows how to block TLS and SSL protocols on your network that are no longer considered secure, such as TLS 1.0, TLS 1.1, and SSLv3. It's included to give you a little more detail about how protocol version rules work.

You should exclude nonsecure protocols from your network because they are all exploitable. In this example:

  • You can block some protocols using Version page on the decryption rule.

  • Because the system considers SSLv2 as undecryptable, you can block it using the Undecryptable Actions on the decryption policy.

  • Similarly, because compressed TLS/SSL is not supported, you should block it as well.


Important

Use the Cipher Suite and Version rule conditions only in rules with either the Block or Block with reset rule actions. Do not use Cipher Suite and Version with either Decrypt - Resign or Decrypt - Known Key rule actions. These conditions in rules with other rule actions can interfere with the system's ClientHello processing, resulting in unpredictable performance.

Procedure

Step 1

Click Policies > Access Control > Decryption.

Step 2

Click Edit (edit icon) next to your decryption policy.

Step 3

Click Edit (edit icon) next to a decryption rule.

Step 4

Click Add Rule.

Step 5

In the Add Rule dialog box, in the Name field, enter a name for the rule.

Step 6

From the Action list, click Block or Block with reset.

Step 7

Click Version page.

Step 8

Check the check boxes for protocols that are no longer secure, such as SSL v3.0, TLS 1.0, and TLS 1.1. Clear the check boxes for any protocols that are still considered secure.

The following figure shows an example.

This sample rule blocks traffic that uses SSL 3.0, TLS 1.0, or TLS 1.1 traffic because such traffic is easily hacked and not secure.

Step 9

Choose other rule conditions as needed.

Step 10

Click Add.

Optional Example: Manual Decryption Rule to Monitor or Block Certificate Distinguished Name

This rule is included to give you an idea about how to monitor or block traffic based on the server certificate's distinguishedname. It's included to give you a little more detail.

The distinguished name can consist of country code, common name, organization, and organizational unit, but typically consists of a common name only. For example, the common name in the certificate for https://www.cisco.com is cisco.com. (However, it's not always this simple; Distinguished Name (DN) Rule Conditions shows how to find common names.)

The host name portion of the URL in the client request is the Server Name Indication (SNI). The client specifies which hostname they want to connect to (for example, auth.amp.cisco.com) using the SNI extension in the TLS handshake. The server then selects the corresponding private key and certificate chain that are required to establish the connection while hosting all certificates on a single IP address.

Procedure

Step 1

Click Policies > Access Control > Decryption.

Step 2

Click Edit (edit icon) next to your decryption policy.

Step 3

Click Edit (edit icon) next to a decryption rule.

Step 4

Click Add Rule.

Step 5

In the Add Rule dialog box, in the Name field, enter a name for the rule.

Step 6

From the Action list, click Block or Block with reset.

Step 7

Click DN.

Step 8

Find the distinguished names you want to add from the Available DNs, as follows:

  • To add a distinguished name object on the fly, which you can then add to the condition, click Add (add icon) above the Available DNs list.

  • To search for distinguished name objects and groups to add, click the Search by name or value prompt above the Available DNs list, then type either the name of the object, or a value in the object. The list updates as you type to display matching objects.

Step 9

To select an object, click it. To select all objects, right-click and then Select All.

Step 10

Click Add to Subject or Add to Issuer.

Tip

 

You can also drag and drop selected objects.

Step 11

Add any literal common names or distinguished names that you want to specify manually. Click the Enter DN or CN prompt below the Subject DNs or Issuer DNs list; then type a common name or distinguished name and click Add.

Although you can add a CN or DN to either list, it's more common to add them to the Subject DNs list.

Step 12

Add or continue editing the rule.

Step 13

When you're done, to save changes to the rule, click Add at the bottom of the page.

Step 14

To save changes to the policy, click Save at the top of the page.

Example

The following figure shows a distinguished name rule condition searching for certificates issued to goodbakery.example.com or issued by goodca.example.com. Traffic encrypted with these certificates is allowed, subject to access control.

This sample rule condition adds the GoodBakery Distinguished Name to the Subject DNs list and its corresponding Common Name to the Issue DNs list. This has the effect of matching traffic on either the subject or the issuer, although it's more common to match on the subject only.

Associate the Decryption Policy with an Access Control Policy and Advanced Settings

This task discusses how to associate the decryption policy with an access control policy and setting recommended advanced settings for the access control policy.

For your decryption policy to be used by the system, you must associate it with an access control policy.

Before you begin

Create the sample decryption policy as discussed in this guide.

For more information about decryption policy advanced options, see Decryption Policy Advanced Options.

Procedure

Step 1

Log in to the Secure Firewall Management Center if you haven't already done so.

Step 2

Click Policies > Access Control.

Step 3

Either create a new access control policy or click Edit (edit icon) to edit an existing one.

Step 4

Click the word Decryption as the following figure shows.

In the firewall management center, for the access control policy, click the word Decryption to select a decryption policy to associate

Step 5

From the list, click the name of your decryption policy and also check Early application detection and URL categorization as the following figure shows.

For the selected decryption policy, select the Early application detection and URL categorization check box

Step 6

Click Apply.

Step 7

Click More > Advanced Settings as the following figure shows.

Select the access control policy's Advanced Settings

Step 8

Click Edit (edit icon) next to TLS Server Identity Discovery.

Step 9

Select the check box as the following figure shows.

In the access control policy's Advanced Settings, select the Server Identity Discovery check box

Step 10

Click OK.

Step 11

At the top of the page, click Save.

Step 12

At the top of the page, click Return to Access Control Policy Management, as the following figure shows

At the top of the page, click Return to Access Control Policy Management

Step 13

Click Edit (edit icon) to edit the access control rule.

Step 14

At the bottom of the page, next to the default action, click (Default Logging and Inspection).

Step 15

Check Log at beginning of connection and any other options you choose.

For more information, see Logging Settings for Access Control PoliciesLogging Settings for Access Control Policies in the Cisco Secure Firewall Management Center Device Configuration Guide.

Step 16

Click Apply.

Step 17

At the top of the page, click Save.

What to do next

Traffic to Prefilter

Prefiltering is the first phase of access control, before the system performs more resource-intensive evaluation. Prefiltering is simple, fast, and early compared to subsequent evaluation, which uses inner headers and has more robust inspection capabilities.

Based on your security needs and traffic profile, you should consider prefiltering and therefore excluding from any policy and inspection the following:

  • Common intraoffice applications such as Microsoft Outlook 365

  • Elephant flows, such as server backups

Decryption Rule Settings

How to configure recommended best practice settings for your decryption rules.

Decryption rules: Enable logging for every rule except those with a Do Not Decrypt rule action. (It's up to you; if you want to see information about traffic that isn't decrypted, enable logging for those rules also.)

Procedure

Step 1

Click Policies > Access Control > Decryption.

Step 2

Click Edit (edit icon) next to your decryption policy.

Step 3

Click Edit (edit icon) next to a decryption rule.

Step 4

Click the Logging tab.

Step 5

Click Log at End of Connection.

Step 6

Click Save.

Step 7

Click Save at the top of the page.