Use SSL decryption rules to determine how to handle encrypted connections. Rules in the SSL decryption policy are evaluated from top to bottom. The rule applied to traffic is the first one where all the traffic criteria are matched.
You can create and edit rules in the SSL Native Rules section only.
Caution: Keep in mind that decrypting and then re-encrypting traffic adds a processing load on the device, which will reduce overall system performance.
Note: Traffic for your VPN connections (both site-to-site and remote access) is decrypted before the SSL decryption policy evaluates connections. Thus, SSL decryption rules are never applied to VPN connections, and you do not need to consider VPN connections when creating these rules. However, any use of encrypted connections within a VPN tunnel are evaluated. For example, an HTTPS connection to an internal server through an RA VPN connection is evaluated by SSL decryption rules, even though the RA VPN tunnel itself is not (because it is decrypted already)
Before you begin
If you have not already, review Configuring SSL Decryption Policies, Enable the SSL Decryption Policy, and Configure the Default SSL Decryption Action to configure the SSL decryption policy your rules will be added to.
If you are creating a decrypt known-key rule, ensure that you upload the certificate and key for the destination server (as an internal certificate) and also edit the SSL decryption policy settings to use the certificate. Known-key rules typically specify the destination server in the destination network criteria of the rule. For more information, see Configure Certificates for Known Key and Re-Sign Decryption.
- Open the Devices & Services page.
- Select the device for which you want to enable the SSL Decryption policy.
- Click Policy in the Management pane at the right.
- Click SSL Decryption in the policy bar.
- Do any of the following:
- To create a new rule, click the blue plus button.
- To edit an existing rule, click the edit icon for the rule.
- To delete a rule you no longer need, click the remove icon for the rule.
- In Order, select where you want to insert the rule in the numbered list of rules.
You can insert rules into the SSL Native Rules section only. The Identity Policy Active Authentication Rules are automatically generated from your identity policy and are read-only.
Rules are applied on a first-match basis, so you must ensure that rules with highly specific traffic matching criteria appear above policies that have more general criteria that would otherwise apply to the matching traffic.
The default is to add the rule to the end of the list. If you want to change a rule's location later, edit this option.
- In Name, enter a name for the rule.
The name cannot contain spaces. You can use alphanumeric characters and these special characters: + . _ -
- Select the action to apply to matching traffic. For a detailed discussion of each option, see the following:
- Source/Destination—The security zones (interfaces) through which the traffic passes, the IP addresses or the country or continent (geographical location) for the IP address, or the TCP ports used in the traffic. The default is any zone, address, geographical location, and TCP port. See Source/Destination Criteria for SSL Decryption Rules.
- URL—The URL category of a web request. The default is that the URL category and reputation are not considered for matching purposes. See URL Criteria for SSL Decryption Rules.
- Application—The application, or a filter that defines applications by type, category, tag, risk, or business relevance. The default is any encrypted application. See Application Criteria for SSL Decryption Rules.
- Users—The user or user group. Your identity policies determine whether user and group information is available for traffic matching. You must configure identity policies to use this criteria. See User Criteria for SSL Decryption Rules.
- Advanced—The characteristics derived from the certificates used in the connection, such as SSL/TLS version and certificate status. See Advanced Criteria for SSL Decryption Rules.
To modify a condition, you click the blue plus button within that condition, select the desired object or element, and click Select in the popup dialog box. If the criterion requires an object, you can click Create New Object if the object you require does not exist. Click the x for an object or element to remove it from the policy.
When adding conditions to SSL decryption rules, consider the following tips:
- You can configure multiple conditions per rule. Traffic must match all the conditions in the rule for the rule to apply to traffic. For example, you can use a single rule to decrypt traffic based on URL category.
- For each condition in a rule, you can add up to 50 criteria. Traffic that matches any of a condition's criteria satisfies the condition. For example, you can use a single rule to apply application control for up to 50 applications or application filters. Thus, there is an OR relationship among the items in a single condition, but an AND relationship between condition types (for example, between source/destination and application).
- Matching URL category requires the URL Filtering license.
- (Optional.) Configure logging for the rule.
You must enable logging for traffic that matches the rule to be included in dashboard data or Event Viewer. Select from these options:
- No logging—Do not generate any events.
- At End of Connection—Generate an event at the conclusion of the connection. Because event storage on the device is limited, sending events to an external syslog server can provide more long term storage and enhance your event analysis.
- Send Connection Events To—If you want to send a copy of the events to an external syslog server, select the server object that defines the syslog server. If the required object does not already exist, click Create and create it. (To disable logging to a syslog server, select Any from the server list.)
If you have a subscription to Cisco Security Analytics and Logging, specify or create a syslog server object using the Secure Event Connector's IP address and port. See Cisco Security Analytics and Logging for more information.
- Click Save.
- Review and deploy now the changes you made, or wait and deploy multiple changes at once.
Source/Destination Criteria for SSL Decryption Rules
The Source/Destination criteria of an SSL decryption rule define the security zones (interfaces) through which the traffic passes, the IP addresses or the country or continent (geographical location) for the IP address, or the TCP ports used in the traffic. The default is any zone, address, geographical location, and any TCP port. TCP is the only protocol matched to SSL decryption rules.
To modify a condition, you click the blue button within that condition, select the desired object or element, and click Select. If the criterion requires an object, you can click Create New Object if the object you require does not exist. Click the x for an object or element to remove it from the policy.
Source Zones, Destination Zones
The security zone objects that define the interfaces through which the traffic passes. You can define one, both, or neither criteria: any criteria not specified applies to traffic on any interface.
- To match traffic leaving the device from an interface in the zone, add that zone to the Destination Zones.
- To match traffic entering the device from an interface in the zone, add that zone to the Source Zones.
- If you add both source and destination zone conditions to a rule, matching traffic must originate from one of the specified source zones and egress through one of the destination zones.
Use this criteria when the rule should apply based on where the traffic enters or exits the device. For example, if you want to ensure that all traffic going from outside hosts to inside hosts gets decrypted, you would select your outside zone as the Source Zones and your inside zone as the Destination Zones.
Source Networks, Destination Networks
The network objects or geographical locations that define the network addresses or locations of the traffic.
- To match traffic from an IP address or geographical location, configure the Source Networks.
- To match traffic to an IP address or geographical location, configure the Destination Networks.
If you add both source and destination network conditions to a rule, matching traffic must originate from one of the specified IP addresses and be destined for one of the destination IP addresses.
When you add this criteria, you select from the following menu options:
- Network—Select the network objects or groups that define the source or destination IP addresses for the traffic you want to control.
Note: For Decrypt Known-Key rules, select an object with the IP address of the destination server that uses the certificate and key you uploaded.
- Country/Continent—Select the geographical location to control traffic based on its source or destination country or continent. Selecting a continent selects all countries within the continent.
- Custom Geolocation-You can also select a geolocation object that you created to define the location. Using geographical location, you could easily restrict access to a particular country without needing to know all of the potential IP addresses used there.
Source Ports, Destination Ports/Protocols
The port objects that define the protocols used in the traffic. You can specify TCP protocol and ports only for SSL decryption rules.
- To match traffic from a TCP port, configure the Source Ports.
- To match traffic to a TCP port, configure the Destination Ports/Protocols.
To match traffic both originating from specific TCP ports and destined for specific TCP ports, configure both. For example, you could target traffic from port TCP/80 to port TCP/8080.
Application Criteria for SSL Decryption Rules
The Application criteria of an SSL decryption rule defines the application used in an IP connection, or a filter that defines applications by type, category, tag, risk, or business relevance. The default is any application that has the SSL Protocol tag. You cannot match SSL decryption rules to any non-encrypted application.
Although you can specify individual applications in the rule, application filters simplify policy creation and administration. For example, you could create an SSL decryption rule that decrypts or blocks all high risk, low business relevance applications. If a user attempts to use one of those applications, the session is decrypted or blocked.
In addition, Cisco frequently updates and adds additional application detectors via system and vulnerability database (VDB) updates. Thus, a rule for high risk applications can automatically apply to new applications without you having to update the rule manually.
You can specify applications and filters directly in the rule, or create application filter objects that define those characteristics. The specifications are equivalent, although using objects can make it easier to stay within the 50-items-per-criteria system limit if you are creating a complex rule.
To modify the application and filters list, you click the button within the condition, select the desired applications or application filter objects, and click Select in the popup dialog box and then click Save. Click the x for an application, filter, or object to remove it from the policy. Click the Save As Filter link to save the combined criteria that is not already an object as a new application filter object.
For more information about the application criteria and how to configure advanced filters and select applications, see Configuring Application Filter Objects.
Consider the following tips when using application criteria in SSL decryption rules:
- The system can identify unencrypted applications that become encrypted using StartTLS. This includes such applications as SMTPS, POPS, FTPS, TelnetS, and IMAPS. In addition, it can identify certain encrypted applications based on the Server Name Indication in the TLS ClientHello message, or the server certificate subject distinguished name value.
- The system can identify the application only after the server certificate exchange. If traffic exchanged during the SSL handshake matches all other conditions in an SSL rule containing an application condition but the identification is not complete, the SSL policy allows the packet to pass. This behavior allows the handshake to complete so that applications can be identified. After the system completes its identification, the system applies the SSL rule action to the remaining session traffic that matches its application condition.
URL Criteria for SSL Decryption Rules
The URL criteria of an SSL decryption rule defines the category to which the URL in a web request belongs. You can also specify the relative reputation of sites to decrypt, block, or allow without decryption. The default is to not match connections based on URL categories.
For example, you could block all encrypted Gaming sites, or decrypt all high risk Social Networking sites. If a user attempts to browse to any URL with that category and reputation combination, the session is blocked or decrypted.
To add URL criteria to an SSL decryption rule:
- Click the URL tab to add a URL category to an SSL Decryption rule.
- Search for and select the URL categories you want to block.
- By default, the traffic from URLs in the categories you pick will be decrypted by the SSL decryption rule no matter their security reputation. However, you can fine-tune the URL category or all the URL categories in your rule to exclude some sites from decryption based on reputation.
- To fine-tune the reputation of a single category in the URL:
- Click the URL category after you selected it.
- Uncheck Any Reputation.
- Slide the green slider to the right to choose the URL reputation settings you want to exclude from the rule and click Save.
The reputations that the slider covers are excluded from the effect of the rule. For example, if you slide the green slider to Benign Sites, Well Known Sites and Benign Sites are excluded from the effects of the SSL Decryption rule for the category you chose. URLs deemed to be Sights with Security Risks, Suspicious Sites, and High Risk Sites will still be affected by the rule for that URL category.
- To fine-tune the reputation of all the URL categories you added to the rule:
- After you have selected all the categories you want to include in the SSL Decryption rule, click Apply Reputation to Selected Categories.
- Uncheck Any Reputation.
- Slide the green slider to the right to choose the URL reputation settings you want to exclude from the rule and click Save.
The reputations that the slider covers are excluded from the effect of the rule. For example, if you slide the green slider to Benign Sites, Well Known Sites and Benign Sites are excluded from the effects of the SSL Decryption rule for all the categories you chose. URLs deemed to be Sights with Security Risks, Suspicious Sites, and High Risk Sites will still be affected by the rule for all the URL categories.
- Click Select.
- Click Save.
User Criteria for SSL Decryption Rules
The User criteria of an SSL decryption rule defines the user or user group for an IP connection. You must configure identity policies and the associated directory server to include user or user group criteria in a rule.
Your identity policies determine whether user identity is collected for a particular connection. If identity is established, the IP address of the host is associated with the identified user. Thus, traffic whose source IP address is mapped to a user is considered to be from that user. IP packets themselves do not include user identity information, so this IP-address-to-user mapping is the best approximation available.
Because you can add a maximum of 50 users or groups to a rule, selecting groups usually makes more sense than selecting individual users. For example, you could create a rule that decrypts traffic to the Engineering group that comes from the outside network, and create a separate rule that does not decrypt outgoing traffic from that group. Then, to make the rule apply to new engineers, you only need to add the engineer to the Engineering group in the directory server.
To modify the users list, you click the + button within the condition and select the desired user groups and click Select.
Advanced Criteria for SSL Decryption Rules
The Advanced traffic matching criteria relate to characteristics derived from the certificates used in the connection. You can configure any or all of the following options.
Traffic matches the certificate properties option of the rule if it matches any of the selected properties. You can configure the following:
- Certificate Status: Whether the certificate is Valid or Invalid. Select Any (the default) if you do not care about certificate status. A certificate is considered valid if all of the following conditions are met, otherwise it is invalid:
- The policy trusts the CA that issued the certificate.
- The certificate’s signature can be properly validated against the certificate’s content.
- The issuer CA certificate is stored in the policy’s list of trusted CA certificates.
- None of the policy’s trusted CAs revoked the certificate.
- The current date is between the certificate Valid From and Valid To dates.
- Self-Signed: Whether the server certificate contains the same subject and issuer distinguished name. Select one of the following:
- Self-Signing—The server certificate is self-signed.
- CA-Signing—The server certificate is signed by a Certificate Authority. That is, the issuer and subject are not the same.
- Any—Do not consider whether the certificate is self-signed as a match criteria.
The SSL/TLS version to match. The rule applies to traffic that uses the any of the selected versions only. The default is all versions. Select from: SSLv3.0, TLSv1.0, TLSv1.1, TLSv1.2.
For example, if you wanted to permit TLSv1.2 connections only, you could create a block rule for the non-TLSv1.2 versions. Traffic that uses any version not listed, such as SSL v2.0, is handled by the default action for the SSL decryption policy.