The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
The following topics provide an overview of creating, configuring, managing, and troubleshooting TLS/SSL rules:
 Note |
Because TLS and SSL are often used interchangeably, we use the expression TLS/SSL to indicate that either protocol is being discussed. The SSL protocol has been deprecated by the IETF in favor of the more secure TLS protocol, so you can usually interpret TLS/SSL as referring to TLS only. The exception is SSL policies. Because the management center configuration option is , we use the term SSL policies although these policies are used to define rules for TLS and SSL traffic. For more information about SSL and TLS protocols, see a resource such as SSL vs. TLS - What's the Difference?. |
TLS/SSL rules provide a granular method of handling encrypted traffic across multiple managed devices, whether blocking the traffic without further inspection, not decrypting the traffic and inspecting it with access control, or decrypting the traffic for access control analysis.
Keep the following points in mind when setting up your TLS/SSL rules. Properly configuring TLS/SSL rules is a complex task, but one that is essential to building an effective deployment that handles encrypted traffic. Many factors influence how you configure rules, including certain application behavior that you cannot control.
In addition, rules can preempt each other, require additional licenses, or contain invalid configurations. Thoughtfully configured rules can also reduce the resources required to process network traffic. Creating overly complex rules and ordering rules the wrong way can adversely affect performance.
For detailed information, see Best Practices for Access Control Rules.
For guidelines related specifically to TLS crypto acceleration, see TLS Crypto Acceleration.
Set up Decrypt - Resign or Decrypt - Known Key rules only if your managed device handles encrypted traffic. TLS/SSL Rules require processing overhead that can impact performance.
You cannot decrypt traffic on a device that has passive or inline tap mode interfaces.
We can determine that certain traffic is not decryptable either because the website itself is not decryptable or because the website uses 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 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 TLS/SSL rules.
An example of setting up a pinned certificate application filter follows.
TLS/SSL traffic cannot be decrypted on passive, inline tap mode, or SPAN interfaces.
Do not use accented characters (for example, Comunicación) in TLS/SSL rule rule names; doing so prevents the policy from being deployed to managed devices.
You should not decrypt traffic if doing so is forbidden by:
Law; for example, some jurisdictions forbid decrypting financial information
Company policy; for example, your company might forbid decrypting privileged communications
Privacy regulations
Traffic that uses certificate pinning (also referred to as TLS/SSL pinning) must remain encrypted to prevent breaking the connection
Encrypted traffic can be allowed or blocked on any TLS/SSL rule condition, including, but not limited to:
Certificate status (for example, expired or invalid certificate)
Protocol (for example, the nonsecure SSL protocol)
Network (security zone, IP address, VLAN tag, and so on)
Exact URL or URL category
Port
User group
You can optionally choose to include categories in your SSL policies. These categories, also referred to as URL filtering, are updated by the Cisco Talos intelligence group. Updates are based on machine learning and human analysis according to content that is retrievable from the website destination and sometimes from its hosting and registration information. Categorization is not based on the declared company vertical, intent, or security. While we strive to continuously update and improve URL filtering categories, it is not an exact science. Some websites are not categorized at all and it's possible some websites might be improperly categorized.
Avoid overusing categories in do not decrypt rules to avoid decrypting traffic without a reason; for example, the Health and Medicine category includes the WebMD website, which does not threaten patient privacy.
Following is a sample decryption policy that can prevent decryption for websites in the Health and Medicine category but allow decryption for WebMD and everything else. General information about decryption rules can be found in Guidelines for Using TLS/SSL Decryption.
Note |
Don't confuse URL filtering with application detection, which relies on reading some of the packet from a website to determine more specifically what it is (for example, Facebook Message or Salesforce). For more information, see Best Practices for Configuring Application Control. |
You can associate one internal Certificate Authority (CA) certificate and private key with the Decrypt - Resign action. If traffic matches this rule, the system re-signs the server certificate with the CA certificate, then acts as a man-in-the-middle. It creates two TLS/SSL sessions, one between client and managed device, one between managed device and server. Each session contains different cryptographic session details, and allows the system to decrypt and reencrypt traffic.
We recommend the following:
Use the Decrypt - Resign rule action for decrypting outgoing traffic, as opposed to incoming traffic for which we recommend the Decrypt - Known Key rule action.
For more information about Decrypt - Known Key, see TLS/SSL Decrypt - Known Key Guidelines.
Always check the Replace Key Only check box when you set up a Decrypt - Resign rule action.
When a user browses to a web site that uses a self-signed certificate, the user sees a security warning in the web browser and is aware that they are communicating with an unsecure site.
When a user browses to a web site that uses a trusted certificate, the user does not see a security warning.
If you configure a rule with the Decrypt - Resign action, the rule matches traffic based on the referenced internal CA certificate’s signature algorithm type, in addition to any configured rule conditions. Because you associate one CA certificate with a Decrypt - Resign action, you cannot create a TLS/SSL rule that decrypts multiple types of outgoing traffic encrypted with different signature algorithms. In addition, any external certificate objects and cipher suites you add to the rule must match the associated CA certificate encryption algorithm type.
For example, outgoing traffic encrypted with an elliptic curve (EC) algorithm matches a Decrypt - Resign rule only if the action references an EC-based CA certificate; you must add EC-based external certificates and cipher suites to the rule to create certificate and cipher suite rule conditions.
Similarly, a Decrypt - Resign rule that references an RSA-based CA certificate matches only outgoing traffic encrypted with an RSA algorithm; outgoing traffic encrypted with an EC algorithm does not match the rule, even if all other configured rule conditions match.
Also note the following:
By nature, anonymous cipher suites are not used for authentication and do not use key exchanges. There are limited uses for anonymous cipher suites; for more information, see RFC 5246, appendix F.1.1.1. (Replaced for TLS 1.3 by RFC 8446 appendix C.5.)
You cannot use the Decrypt - Resign or Decrypt - Known Key action in the rule because anonymous cipher suites are not used for authentication.
To use a Decrypt - Resign rule action, you should create a Certificate Signing Request (CSR) and have it signed by a trusted certificate authority. (You can use the FMC to create a CSR: .)
To be used in a Decrypt - Resign rule, your certificate authority (CA) must have at least one of the following extensions:
CA: TRUE
For more information, see the discussion of Basic Constraints in RFC3280, section 4.2.1.10.
KeyUsage=CertSign
For more information see RFC 5280, section 4.2.1.3.
To verify your CSR or CA has at least one of the preceding extensions, you can use the openssl command as discussed in a reference such as the openssl documentation.
This is necessary because for Decrypt - Resign inspection to work, the certificate that used in the SSL policy generates certificates on-the-fly and signs them so as to act as man-in-the middle and proxy all TLS/SSL connections.
If the customer's browser uses certificate pinning to verify a server certificate, you cannot decrypt this traffic by re-signing the server certificate. To allow this traffic, configure a TLS/SSL rule with the Do not decrypt action to match the server certificate common name or distinguished name.
The following error is displayed if you attempt to save a TLS/SSL rule with a cipher suite that does not match the certificate. To resolve the issue, see Verify TLS/SSL Cipher Suites.
Traffic cannot match this rule; none of your selected cipher suites contain a
signature algorithm that the resigning CA's signature algorithmIf the client does not trust the Certificate Authority (CA) used to re-sign the server certificate, it warns the user that the certificate should not be trusted. To prevent this, import the CA certificate into the client trusted CA store. Alternatively, if your organization has a private PKI, you can issue an intermediate CA certificate signed by the root CA which is automatically trusted by all clients in the organization, then upload that CA certificate to the device.
The system cannot decrypt traffic if an HTTP proxy is positioned between a client and your managed device, and the client and server establish a tunneled TLS/SSL connection using the CONNECT HTTP method. The Handshake Errors undecryptable action determines how the system handles this traffic.
If you create an internal CA object and choose to generate a certificate signing request (CSR), you cannot use this CA for a Decrypt - Resign action until you upload the signed certificate to the object.
If you configure a rule with the Decrypt - Resign action, and mismatch signature algorithm type for one or more external certificate objects or cipher suites, the policy editor
displays an Information
(
) next to the rule. If you mismatch signature algorithm type for all external certificate objects, or all cipher suites, the
policy displays a warning icon Warning (
) next to the rule, and you cannot deploy the access control policy associated with the SSL policy.
When you configure the Decrypt - Known Key action, you can associate one or more server certificates and paired private keys with the action. If traffic matches the rule, and the certificate used to encrypt the traffic matches the certificate associated with the action, the system uses the appropriate private key to obtain the session encryption and decryption keys. Because you must have access to the private key, this action is best suited to decrypt traffic incoming to servers your organization controls.
Also note the following:
By nature, anonymous cipher suites are not used for authentication and do not use key exchanges. There are limited uses for anonymous cipher suites; for more information, see RFC 5246, appendix F.1.1.1. (Replaced for TLS 1.3 by RFC 8446 appendix C.5.)
You cannot use the Decrypt - Resign or Decrypt - Known Key action in the rule because anonymous cipher suites are not used for authentication.
You cannot match on Distinguished Name or Certificate conditions when creating a TLS/SSL rule with a Decrypt - Known Key action. The assumption is that if this rule matches traffic, the certificate, subject DN, and issuer DN already match the certificate associated with the rule.
If decrypted traffic matches an access control rule with an action of Interactive Block or Interactive Block with reset, the system displays a customizable response page.
Provided you enabled logging in your rule, two connection events are displayed (in ): One event for the interactive block and another event to indicate whether or not the user chose to continue to the site or not.
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 TLS/SSL 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. You have the following options:
Create a Do Not Decrypt for those applications rule ordered before Decrypt - Resign rules.
Instruct users to access the applications using a web browser.
For more information about rule ordering, see SSL Rule Order.
To determine whether applications are using TLS/SSL pinning, see Troubleshoot TLS/SSL Pinning.
Some applications use the TLS heartbeat extension to the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols defined by RFC6520. TLS heartbeat provides a way to confirm the connection is still alive—either the client or server sends a specified number of bytes of data and requests the other party echo the response. If this is successful, encrypted data is sent.
You can configure a Max Heartbeat Length in a Network Analysis Policy (NAP) to determine how to handle TLS heartbeats. For more information, see The SSL Preprocessor.
For more information, see About TLS Heartbeat.
By nature, anonymous cipher suites are not used for authentication and do not use key exchanges. There are limited uses for anonymous cipher suites; for more information, see RFC 5246, appendix F.1.1.1. (Replaced for TLS 1.3 by RFC 8446 appendix C.5.)
You cannot use the Decrypt - Resign or Decrypt - Known Key action in the rule because anonymous cipher suites are not used for authentication.
You can add an anonymous cipher suite to the Cipher Suite condition in a TLS/SSL rule, but the system automatically strips anonymous cipher suites during ClientHello processing. For the system to use the rule, you must also configure your TLS/SSL rules in an order that prevents ClientHello processing. For more information, see SSL Rule Order.
If you enable the Normalize Excess Payload option in the inline normalization preprocessor, when the preprocessor normalizes decrypted traffic, it might drop a packet and replace it with a trimmed packet. This does not end the TLS/SSL session. If the traffic is allowed, the trimmed packet is encrypted as part of the TLS/SSL session.
If you add a group or user to a rule, then change your realm settings to exclude that group or user, the rule has no effect. (The same applies to disabling the realm.) For more information about realms, see Create an LDAP Realm or an Active Directory Realm and Realm Directory.
If your SSL policy has a Decrypt - Resign action but web sites are not being decrypted, check Category page on rules associated with that policy.
In some cases, a web site redirects to another site for authentication or other purposes and the redirected site might have a different URL categorization than the site you're trying to decrypt. For example, gmail.com (Web based email category) redirects to accounts.gmail.com (Internet Portals category) for authentication. Be sure to include all relevant categories in the SSL rule.
Note |
In order to fully process traffic based on URL category, you must also configure URL filtering. See the URL Filtering chapter. |
If you create a Decrypt - Resign rule and users browse to a web site whose category and reputation are not in the local database, data might not be decrypted. Some web sites are not categorized in the local database and, if not, data from those web sites is not decrypted by default.
You can control this behavior with the setting System > Integration > Cloud Services , and check Query Cisco cloud for unknown URLs.
For more information about this option, see Cisco Cloudsƒ in the Cisco Secure Firewall Management Center Administration Guide.
Any
Admin
Access Admin
Network Admin
The system matches traffic to TLS/SSL rules in the order you specify. In most cases, the system handles encrypted traffic according to the first TLS/SSL rule where all the rule’s conditions match the traffic. Conditions can be simple or complex; you can control traffic by security zone, network or geographical location, VLAN, port, application, requested URL, user, certificate, certificate distinguished name, certificate status, cipher suite, or encryption protocol version.
Each rule also has an action, which determines whether you monitor, block, or inspect matching encrypted or decrypted traffic with access control. Note that the system does not further inspect encrypted traffic it blocks. It does inspect encrypted and undecryptable traffic with access control. However, some access control rule conditions require unencrypted traffic, so encrypted traffic may match fewer rules. Also, by default, the system disables intrusion and file inspection of encrypted payloads.
The following scenario summarizes the ways that TLS/SSL rules handle traffic in an inline deployment.
In this scenario, traffic is evaluated as follows:
Undecryptable Traffic Action evaluates encrypted traffic first. For traffic the system cannot decrypt, the system either blocks it without further inspection or passes it for access control inspection. Encrypted traffic that does not match continues to the next rule.
TLS/SSL Rule 1: Monitor evaluates encrypted traffic next. Monitor rules track and log encrypted traffic but do not affect traffic flow. The system continues to match traffic against additional rules to determine whether to permit or deny it.
TLS/SSL Rule 2: Do Not Decrypt evaluates encrypted traffic third. Matching traffic is not decrypted; the system inspects this traffic with access control, but not file or intrusion inspection. Traffic that does not match continues to the next rule.
TLS/SSL Rule 3: Block evaluates encrypted traffic fourth. Matching traffic is blocked without further inspection. Traffic that does not match continues to the next rule.
TLS/SSL Rule 4: Decrypt - Known Key evaluates encrypted traffic fifth. Matching traffic incoming to your network is decrypted using a private key you upload. The decrypted traffic is then evaluated against access control rules. Access control rules handle decrypted and unencrypted traffic identically. The system can block traffic as a result of this additional inspection. All remaining traffic is reencrypted before being allowed to the destination. Traffic that does not match the TLS/SSL rule continues to the next rule.
TLS/SSL Rule 5: Decrypt - Resign is the final rule. If traffic matches this rule, the system re-signs the server certificate with an uploaded CA certificate, then acts as a man-in-the-middle to decrypt traffic. The decrypted traffic is then evaluated against access control rules. Access control rules treat decrypted and unencrypted traffic identically. The system can block traffic as a result of this additional inspection. All remaining traffic is reencrypted before being allowed to the destination. Traffic that does not match the SSL rule continues to the next rule.
SSL policy Default Action handles all traffic that does not match any of the TLS/SSL rules. The default action either blocks encrypted traffic without further inspection or does not decrypt it, passing it for access control inspection.
You must create reusable public key infrastructure (PKI) objects to control encrypted traffic based on encrypted session characteristics and decrypt encrypted traffic. You can add this information on the fly when uploading trusted certificate authority (CA) certificates to the an SSL policy and creating TLS/SSL rule, creating the associated object in the process. However, configuring these objects ahead of time reduces the chance of improper object creation.
The system can decrypt incoming encrypted traffic if you configure an internal certificate object by uploading the server certificate and private key used to encrypt the session. If you reference that object in an SSL policy rule with an action of Decrypt - Known Key and traffic matches that rule, the system uses the uploaded private key to decrypt the session.
The system can also decrypt outgoing traffic if you configure an internal CA object by uploading a CA certificate and private key. If you reference that object in a TLS/SSL rule with an action of Decrypt - Resign and traffic matches that rule, the system re-signs the server certificate passed to the client browser, then acts as a man-in-the-middle to decrypt the session. You can optionally replace the self-signed certificate key only and not the entire certificate, in which case users see a self-signed certificate key notice in the browser.
The system can control encrypted traffic based on the cipher suite or server certificate used to negotiate the session. You can configure one of several different reusable objects and reference the object in a TLS/SSL rule condition to match traffic. The following table describes the different types of reusable objects you can configure:
|
If you configure... |
You can control encrypted traffic based on whether... |
|---|---|
|
A cipher suite list containing one or more cipher suites |
The cipher suite used to negotiate the encrypted session matches a cipher suite in the cipher suite list |
|
A trusted CA object by uploading a CA certificate your organization trusts |
The trusted CA trusts the server certificate used to encrypt the session, whether:
|
|
An external certificate object by uploading a server certificate |
The server certificate used to encrypt the session matches the uploaded server certificate |
|
A distinguished name object containing a certificate subject or issuer distinguished name |
The subject or issuer common name, country, organization, or organizational unit on the certificate used to encrypt the session matches the configured distinguished name |
When you create the TLS/SSL rule in an SSL policy, you specify its position using the Insert list in the rule editor. TLS/SSL rules in an an SSL policy are numbered, starting at 1. The system matches traffic to TLS/SSL rules in top-down order by ascending rule number.
In most cases, the system handles network traffic according to the first TLS/SSL rule where all the rule’s conditions match the traffic. Except in the case of Monitor rules (which log traffic but do not affect traffic flow), the system does not continue to evaluate traffic against additional, lower-priority rules after that traffic matches a rule. Conditions can be simple or complex; you can control traffic by security zone, network or geographical location, VLAN, port, application, requested URL, user, certificate, certificate distinguished name, certificate status, cipher suite, or encryption protocol version.
Each rule also has an action, which determines whether you monitor, block, or inspect matching encrypted or decrypted traffic with access control. Note that the system does not further inspect encrypted traffic it blocks. It does subject encrypted and undecryptable traffic to access control. However, access control rule conditions require unencrypted traffic, so encrypted traffic matches fewer rules.
Rules that use specific conditions (such as network and IP addresses) should be ordered before rules that use general conditions (such as applications). If you're familiar with the Open Systems Interconnect (OSI) model, use similar numbering in concept. Rules with conditions for layers 1, 2, and 3 (physical, data link, and network) should be ordered first in your rules. Conditions for layers 5, 6, and 7 (session, presentation, and application) should be ordered later in your rules. For more information about the OSI model, see this Wikipedia article.
 Tip |
Proper TLS/SSL rule order reduces the resources required to process network traffic, and prevents rule preemption. Although the rules you create are unique to every organization and deployment, there are a few general guidelines to follow when ordering rules that can optimize performance while still addressing your needs. |
In addition to ordering rules by number, you can group rules by category. By default the system provides three categories: Administrator, Standard, and Root. You can add custom categories, but you cannot delete the system-provided categories or change their order.
A TLS/SSL rule’s conditions identify the type of encrypted traffic the rule handles. Conditions can be simple or complex, and you can specify more than one condition type per rule. Only if traffic meets all the conditions in a rule does the rule apply to the traffic.
If you do not configure a particular condition for a rule, the system does not match traffic based on that criterion. For example, a rule with a certificate condition but no version condition evaluates traffic based on the server certificate used to negotiate the session, regardless of the session SSL or TLS version.
Every TLS/SSL rule has an associated action that determines the following for matching encrypted traffic:
Handling: Most importantly, the rule action governs whether the system will monitor, trust, block, or decrypt encrypted traffic that matches the rule’s conditions
Logging: The rule action determines when and how you can log details about matching encrypted traffic.
Your TLS/SSL inspection configuration handles, inspects, and logs decrypted traffic:
The SSL policy’s undecryptable actions handle traffic that the system cannot decrypt.
The policy’s default action handles traffic that does not meet the condition of any non-Monitor TLS/SSL rule.
You can log a connection event when the system blocks or trusts an encrypted session. You can also force the system to log connections that it decrypts for further evaluation by access control rules, regardless of how the system later handles or inspects the traffic. Connection logs for encrypted sessions contain details about the encryption, such as the certificate used to encrypt that session. You can log only end-of-connection events, however:
For blocked connections (Block, Block with reset), the system immediately ends the sessions and generates an event
For Do Not Decrypt connections, the system generates an event when the session ends
Leave matching criteria empty whenever possible, especially those for security zones, network objects, and port objects. When you specify multiple criteria, the system must match against every combination of the contents of the criteria you specify.
 Caution |
Adding the first or removing the last active authentication rule when TLS/SSL decryption is disabled (that is, when the access control policy does not include an SSL policy) restarts the Snort process when you deploy configuration changes, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on how the target device handles traffic. See Snort Restart Traffic Behavior for more information. Note that an active authentication rule has either an Active Authentication rule action, or a Passive Authentication rule action with Use active authentication if passive or VPN identity cannot be established selected. |
Security zones segment your network to help you manage and classify traffic flow by grouping interfaces across multiple devices.
Zone rule conditions control traffic by its source and destination security zones. If you add both source and destination zones to a zone condition, matching traffic must originate from an interface in one of the source zones and leave through an interface in one of the destination zones.
Just as all interfaces in a zone must be of the same type (all inline, passive, switched, or routed), all zones used in a zone condition must be of the same type. Because devices deployed passively do not transmit traffic, you cannot use a zone with passive interfaces as a destination zone.
Leave matching criteria empty whenever possible, especially those for security zones, network objects, and port objects. When you specify multiple criteria, the system must match against every combination of the contents of the criteria you specify.
Tip |
Constraining rules by zone is one of the best ways to improve system performance. If a rule does not apply to traffic through any of device’s interfaces, that rule does not affect that device's performance. |
In a multidomain deployment, a zone created in an ancestor domain can contain interfaces that reside on devices in different domains. When you configure a zone condition in an descendant domain, your configurations apply to only the interfaces you can see.
Network rule conditions control traffic by its source and destination IP address, using inner headers. Tunnel rules, which use outer headers, have tunnel endpoint conditions instead of network conditions.
You can use predefined objects to build network conditions, or manually specify individual IP addresses or address blocks.
Note |
You cannot use FDQN network objects in identity rules. |
Leave matching criteria empty whenever possible, especially those for security zones, network objects, and port objects. When you specify multiple criteria, the system must match against every combination of the contents of the criteria you specify.
Note |
VLAN tags in access rules only apply to inline sets. Access rules with VLAN tags do not match traffic on firewall interfaces. |
VLAN rule conditions control VLAN-tagged traffic, including Q-in-Q (stacked VLAN) traffic. The system uses the innermost VLAN tag to filter VLAN traffic, with the exception of the prefilter policy, which uses the outermost VLAN tag in its rules.
Note the following Q-in-Q support:
Threat Defense on Firepower 4100/9300—Does not support Q-in-Q (supports only one VLAN tag).
Threat Defense on all other models:
Inline sets and passive interfaces—Supports Q-in-Q, up to 2 VLAN tags.
Firewall interfaces—Does not support Q-in-Q (supports only one VLAN tag).
You can use predefined objects to build VLAN conditions, or manually enter any VLAN tag from 1 to 4094. Use a hyphen to specify a range of VLAN tags.
You can specify a maximum of 50 VLAN conditions.
In a cluster, if you encounter problems with VLAN matching, edit the access control policy advanced options, Transport/Network Preprocessor Settings, and select the Ignore the VLAN header when tracking connections option.
User rule conditions match traffic based the user who initiates the connection, or the group to which the user belongs. For example, you could configure a Block rule to prohibit anyone in the Finance group from accessing a network resource.
For access control rules only, you must first associate an identity policy with the access control policy as discussed in Associating Other Policies with Access Control.
In addition to configuring users and groups for configured realms, you can set policies for the following Special Identities users:
Failed Authentication: User that failed authentication with the captive portal.
Guest: Users configured as guest users in the captive portal.
No Authentication Required: Users that match an identity No Authentication Required rule action.
Unknown: Users that cannot be identified; for example, users that are not downloaded by a configured realm.
When the system analyzes IP traffic, it can identify and classify the commonly used applications on your network. This discovery-based application awareness is the basis for application control—the ability to control application traffic.
System-provided application filters help you perform application control by organizing applications according to basic characteristics: type, risk, business relevance, category, and tags. You can create reuseable user-defined filters based on combinations of the system-provided filters, or on custom combinations of applications.
At least one detector must be enabled for each application rule condition in the policy. If no detector is enabled for an application, the system automatically enables all system-provided detectors for the application; if none exist, the system enables the most recently modified user-defined detector for the application. For more information about application detectors, see Application Detector Fundamentals.
You can use both application filters and individually specified applications to ensure complete coverage. However, understand the following note before you order your access control rules.
Application filters help you quickly configure application control. For example, you can easily use system-provided filters to create an access control rule that identifies and blocks all high risk, low business relevance applications. If a user attempts to use one of those applications, the system blocks the session.
Using application filters simplifies policy creation and administration. It assures you that the system controls application traffic as expected. Because Cisco frequently updates and adds application detectors via system and vulnerability database (VDB) updates, you can ensure that the system uses up-to-date detectors to monitor application traffic. You can also create your own detectors and assign characteristics to the applications they detect, automatically adding them to existing filters.
The system characterizes each application that it detects using the criteria described in the following table. Use these characteristics as application filters.
|
Characteristic |
Description |
Example |
|---|---|---|
|
Type |
Application protocols represent communications between hosts. Clients represent software running on a host. Web applications represent the content or requested URL for HTTP traffic. |
HTTP and SSH are application protocols. Web browsers and email clients are clients. MPEG video and Facebook are web applications. |
|
Risk |
The likelihood that the application is being used for purposes that might be against your organization’s security policy. |
Peer-to-peer applications tend to have a very high risk. |
|
Business Relevance |
The likelihood that the application is being used within the context of your organization’s business operations, as opposed to recreationally. |
Gaming applications tend to have a very low business relevance. |
|
Category |
A general classification for the application that describes its most essential function. Each application belongs to at least one category. |
Facebook is in the social networking category. |
|
Tag |
Additional information about the application. Applications can have any number of tags, including none. |
Video streaming web applications often are tagged high bandwidth and displays ads. |
Port conditions allow you to control traffic by its source and destination ports.
Leave matching criteria empty whenever possible, especially those for security zones, network objects, and port objects. When you specify multiple criteria, the system must match against every combination of the contents of the criteria you specify.
Specifying ports is the traditional way to target applications. However, applications can be configured to use unique ports to bypass access control blocks. Thus, whenever possible, use application filtering criteria rather than port criteria to target traffic.
Application filtering is also recommended for applications, like threat defense, that open separate channels dynamically for control vs. data flow. Using port-based access control rules can prevent these kinds of applications from performing correctly, and could result in blocking desirable connections.
If you add both source and destination port constraints, you can only add ports that share a single transport protocol (TCP or UDP). For example, if you add DNS over TCP as a source port, you can add Yahoo Messenger Voice Chat (TCP) as a destination port but not Yahoo Messenger Voice Chat (UDP).
If you add only source ports or only destination ports, you can add ports that use different transport protocols. For example, you can add both DNS over TCP and DNS over UDP as source port conditions in a single access control rule.
You can optionally choose to include categories in your SSL policies. These categories, also referred to as URL filtering, are updated by the Cisco Talos intelligence group. Updates are based on machine learning and human analysis according to content that is retrievable from the website destination and sometimes from its hosting and registration information. Categorization is not based on the declared company vertical, intent, or security.
For more information, see URL Filtering Overview.
If you are using category rule conditions in SSL policies in a rule with the Do Not Decrypt rule action, see TLS/SSL Rule Do Not Decrypt Action.
TLS/SSL rules can handle and decrypt encrypted traffic based on server certificate characteristics. You can configure TLS/SSL rules based on the following server certificate attributes:
Distinguished name conditions allow you to handle and inspect encrypted traffic based on the CA that issued a server certificate, or the certificate holder. Based on the issuer distinguished name, you can handle traffic based on the CA that issued a site’s server certificate.
Certificate conditions in TLS/SSL rules allow you to handle and inspect encrypted traffic based on the server certificate used to encrypt that traffic. You can configure a condition with one or more certificates; traffic matches the rule if the certificate matches any of the condition’s certificates.
Certificate status conditions in TLS/SSL rules allow you to handle and inspect encrypted traffic based on the status of the server certificate used to encrypt the traffic, including whether a certificate is valid, revoked, expired, not yet valid, self-signed, signed by a trusted CA, whether the Certificate Revocation List (CRL) is valid; whether the Server Name Indication (SNI) in the certificate matches the server in the request.
Cipher suite conditions in TLS/SSL rules allow you to handle and inspect encrypted traffic based on the cipher suite used to negotiate the encrypted session.
Session conditions in TLS/SSL rules allow you to inspect encrypted traffic based on the SSL or TLS version used to encrypt the traffic.
To detect multiple cipher suites in a rule, the certificate issuer, or the certificate holder, you can create reusable cipher suite list and distinguished name objects and add them to your rule. To detect the server certificate and certain certificate statuses, you must create external certificate and external CA objects for the rule.
When you build a certificate-based TLS/SSL rule condition, you can upload a server certificate; you save the certificate as an external certificate object, which is reusable and associates a name with a server certificate. Alternately, you can configure certificate conditions with existing external certificate objects and object groups.
You can search the Available Certificates field in the rule condition based for external certificate objects and object groups based on the following certificate distinguished name characteristics:
Subject or issuer common name (CN), or if the URL is contained in the certificate's Subject Alternative Name (SAN)
The URL the user enters in the browser matches the Common Name (CN)
Subject or issuer organization (O)
Subject or issuer organizational unit (OU)
You can choose to match against multiple certificates in a single certificate rule condition; if the certificate used to encrypt the traffic matches any of the uploaded certificates, the encrypted traffic matches the rule.
You can add a maximum of 50 external certificate objects and external certificate object groups to the Selected Certificates in a single certificate condition.
Note the following:
You cannot configure a certificate condition if you also select the Decrypt - Known Key action. Because that action requires you to select a server certificate to decrypt traffic, the implication is that the certificate already matches the traffic.
If you configure a certificate condition with an external certificate object, any cipher suites you add to a cipher suite condition, or internal CA objects you associate with the Decrypt - Resign action, must match the external certificate’s signature algorithm type. For example, if your rule’s certificate condition references an EC-based server certificate, any cipher suites you add, or CA certificates you associate with the Decrypt - Resign action, must also be EC-based. If you mismatch signature algorithm types in this case, the policy editor displays a warning next to the rule.
The first time the system detects an encrypted session to a new server, certificate data is not available for ClientHello processing, which can result in an undecrypted first session. After the initial session, the managed device caches data from the server Certificate message. For subsequent connections from the same client, the system can match the ClientHello message conclusively to rules with certificate conditions and process the message to maximize decryption potential.
This topic discusses how to use distinguished name conditions in a TLS/SSL rule. If you're not sure, you can find a certificate's Subject Alternative Name (SAN) and Common Name using a web browser, then you can add those values to a TLS/SSL rule as distinguished name conditions.
For detailed information about SANs, see RFC 528, section 4.2.1.6.
The following sections discuss:
Following is an example of DN rule conditions in a Do Not Decrypt rule. Suppose you want to make sure to not decrypt traffic going to amp.cisco.com or to YouTube. You could set up your DN conditions as follows:
The preceding DN rule conditions would match the following URLs and therefore, the traffic would be undecrypted an earlier rule prevented it:
www.amp.cisco.com
auth.amp.cisco.com
auth.us.amp.cisco.com
www.youtube.com
kids.youtube.com
www.yt.be
The preceding DN rule conditions would not match any of the following URLs and therefore, the traffic would not match the Do Not Decrypt rule but might match any other TLS/SSL rules in the same SSL policy.
amp.cisco.com
youtube.com
yt.be
To match any of the preceding host names, add more CNs to the rule (for example, adding CN=yt.be would match that URL.)
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.
If there's a match between the SNI and the CN or a SAN in the certificate, we use the SNI when comparing against the DNs listed in the rule. If there is no SNI or if it doesn't match the certificate, we use the certificate's CN when comparing against the DNs listed in the rule.
To find any certificate's Common Name, use the following steps. You can even use these steps to find the common name and SANs for a self-signed certificate.
These steps are for Firefox but other browsers are similar. The following procedure uses amp.cisco.com as an example.
Browse to amp.cisco.com in Firefox.
In the browser's location bar, to the left of the URL, click 
.
Click .
(For a non-secure or self-signed certificate, click .)
On the Page Info dialog box, click View Certificate.
The next page shows certificate details.
Note the following:
CN=auth.amp.cisco.com, if used as a DN rule condition, would match only that host name (that is, SNI). The SNI amp.cisco.com would not match.
To match as many domain name fields as possible, use wildcards.
For example, to match auth.amp.cisco.com, use CN=*.amp.cisco.com. To match auth.us.amp.cisco.com, use CN=*.*.amp.cisco.com.
A DN like CN=*.example.com matches www.example.com but not
example.com. To match both SNIs, use two DNs in the rule condition.
Don't go overboard with wildcards though. For example, a DN object like CN=*.google.com matches a very large number of SANs. Instead of CN=*.google.com, use a DN object like CN=*.youtube.com as the DN object so it matches names like www.youtube.com.
You can also use variations of the SNI that match SANs like CN=*.youtube.com, CN=youtu.be, CN=*.yt.be, and so on.
A self-signed certificate should work the same way. You can confirm it's a self-signed certificate by the fact the issuer DN is the same as the subject DN.
After you know the CN you want to match, edit the TLS/SSL rule in one of the following ways:
Use an existing DN.
Click the name of a DN and then click either Add to Subject or Add to Issuer. (Add to Subject is much more common.) To view the value of a DN object, hover the mouse pointer over it.)
Create a new DN object.
Click Add (
) to the right of Available DNs. The DN object must consist of a name and a value.
Add the DN directly.
Enter the DN in the field at the bottom of the Subject DNs field or the Issuer DNs field. (Subject DNs is more common.) After you enter the DN, click Add.
You can trust CAs by adding root and intermediate CA certificates to your SSL policy, then use these trusted CAs to verify server certificates used to encrypt traffic.
If a trusted CA certificate contains an uploaded certificate revocation list (CRL), you can also verify whether a trusted CA revoked the encryption certificate.
Tip |
Upload all certificates in a root CA’s chain of trust to the list of trusted CA certificates, including the root CA certificate and all intermediate CA certificates. Otherwise, it is more difficult to detect trusted certificates issued by intermediate CAs. Also, if you configure certificate status conditions to trust traffic based on the root issuer CA, all traffic within a trusted CA’s chain of trust can be allowed without decryption, rather than unnecessarily decrypting it. For more information, see Trusted CA Object. |
Note |
When you create an SSL policy, the policy's Trusted CA Certificate tab page is populated with several trusted CA certificates, including the Cisco-Trusted-Authorities group, which is added to the Select Trusted CAs list. |
|
Step 1 |
Log in to the management center if you haven't already done so. |
||
|
Step 2 |
Click . |
||
|
Step 3 |
Click Edit ( |
||
|
Step 4 |
Click Add Rule to add a new TLS/SSL
rule or click Edit ( |
||
|
Step 5 |
Click the Certificates tab. |
||
|
Step 6 |
Find the trusted CAs you want to add from the Available Certificates, as follows:
|
||
|
Step 7 |
To select an object, click it. To select all objects, right-click and then Select All. |
||
|
Step 8 |
Click Add to Rule.
|
||
|
Step 9 |
Add or continue editing the rule. |
Add a certificate status TLS/SSL rule condition to your SSL rule. See Matching Traffic on Certificate Status for more information.
Deploy configuration changes; see Deploy Configuration Changes.
For each certificate status TLS/SSL rule you configure, you can match traffic against the presence or absence of a given status. You can select several statuses in one rule condition; if the certificate matches any of the selected statuses, the rule matches the traffic.
You can choose to match against the presence or absence of multiple certificate statuses in a single certificate status rule condition; the certificate needs to match only one of the criteria to match the rule.
You should consider, when setting this parameter, whether you're configuring a decrypt rule or a block rule. Typically, you should click Yes for a block rule and No for a decrypt rule. Examples:
If you're configuring a Decrypt - Resign rule, the default behavior is to decrypt traffic with an expired certificate. To change that behavior, click No for Expired so traffic with an expired certificate is not decrypted and resigned.
If you're configuring a Block rule, the default behavior is to allow traffic with an expired certificate. To change that behavior click Yes for Expired so traffic with an expired certificate is blocked.
The following table describes how the system evaluates encrypted traffic based on the encrypting server certificate’s status.
|
Status Check |
Status Set to Yes |
Status Set to No |
|---|---|---|
|
Revoked |
The policy trusts the CA that issued the server certificate, and the CA certificate uploaded to the policy contains a CRL that revokes the server certificate. |
The policy trusts the CA that issued the server certificate, and the CA certificate uploaded to the policy does not contain a CRL that revokes the certificate. |
|
Self-signed |
The detected server certificate contains the same subject and issuer distinguished name. |
The detected server certificate contains different subject and issuer distinguished names. |
|
Valid |
All of the following are true:
|
At least one of the following is true:
|
|
Invalid signature |
The certificate’s signature cannot be properly validated against the certificate’s content. |
The certificate’s signature is properly validated against the certificate’s content. |
|
Invalid issuer |
The issuer CA certificate is not stored in the policy’s list of trusted CA certificates. |
The issuer CA certificate is stored in the policy’s list of trusted CA certificates. |
|
Expired |
The current date is after the certificate Valid To date. |
The current date is before or on the certificate Valid To date. |
|
Not yet valid |
The current date is before the certificate Valid From date. |
The current date is after or on the certificate Valid From date. |
|
Invalid certificate |
The certificate is not valid. At least one of the following is true:
|
The certificate is valid. All of the following are true:
|
|
Invalid CRL |
The Certificate Revocation List (CRL) digital signature is not valid. At least one of the following is true:
|
The CRL is valid. All of the following are true:
|
|
Server mismatch |
The server name does not match the server's Server Name Indication (SNI) name, which could indicate an attempt to spoof the server name. |
The server name matches the SNI name of the server to which the client is requesting access. |
Note that even though a certificate might match more than one status, the rule causes an action to be taken on the traffic only once.
Checking whether a CA issued or revoked a certificate requires uploading root and intermediate CA certificates and associated CRLs as objects. You then add these trusted CA objects to an SSL policy’s list of trusted CA certificates.
The system provides predefined cipher suites you can add to a cipher suite rule condition for Block or Block with Reset rule actions. You can also add cipher suite list objects containing multiple cipher suites.
Important |
Cipher suite rule conditions should be used only to block traffic, never to decrypt traffic. |
Note |
You cannot add new cipher suites. You can neither modify nor delete predefined cipher suites. |
You can add a maximum of 50 cipher suites and cipher suite lists to the Selected Cipher Suites in a single cipher suite condition. The system supports adding the following cipher suites to a cipher suite condition:
SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
SSL_RSA_FIPS_WITH_DES_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_DH_Anon_WITH_AES_128_GCM_SHA256
TLS_DH_Anon_WITH_AES_256_GCM_SHA384
TLS_DH_Anon_WITH_CAMELLIA_128_CBC_SHA
TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256
TLS_DH_Anon_WITH_CAMELLIA_256_CBC_SHA
TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_NULL_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_NULL_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256
TLS_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
Note the following:
If you add cipher suites not supported for your deployment, you cannot deploy your configuration. For example, passive deployments do not support decrypting traffic with the any of the ephemeral Diffie-Hellman (DHE) or ephemeral elliptic curve Diffie-Hellman (ECDHE) cipher suites. Creating a rule with these cipher suites prevents you from deploying your access control policy.
You can add an anonymous cipher suite to the Cipher Suite condition in SSL policy to use the rule, you must also configure your in an order that prevents ClientHello processing. For more information, see SSL Rule Order.
When specifying a cipher suite as a rule condition, consider that the rule matches on the negotiated cipher suite in the ServerHello message, rather than on the full list of cipher suites specified in the ClientHello message. During ClientHello processing, the managed device strips unsupported cipher suites from the ClientHello message. However, if this results in all specified cipher suites being stripped, the system retains the original list. If the system retains unsupported cipher suites, subsequent evaluation results in an undecrypted session.
You can choose to match against traffic encrypted with SSL version 3.0, or TLS version 1.0, 1.1, or 1.2. By default, all protocol versions are selected when you create a rule; if you select multiple versions, encrypted traffic that matches any of the selected versions matches the rule. You must select at least one protocol version when saving the rule condition.
You can use SSL 3.0 in a Do Not Decrypt, Block, or Block with Reset rule action.
You cannot select SSL v2.0 in a version rule condition; the system does not support decrypting traffic encrypted with SSL version 2.0. You can configure an undecryptable action to allow or block this traffic without further inspection. For more information, see Set Default Handling for Undecryptable Traffic.
The following sections discuss the actions available with TLS/SSL rules.
The Monitor action is not designed to permit or deny traffic. Rather, its primary purpose is to force connection logging, regardless of how matching traffic is eventually handled. The ClientHello message is not modified if traffic matches a Monitor rule condition.
Traffic is then matched against additional rules, if present, to determine whether to trust, block, or decrypt it. The first non-Monitor rule matched determines traffic flow and any further inspection. If there are no additional matching rules, the system uses the default action.
Because the primary purpose of Monitor rules is to track network traffic, the system automatically logs end-of connection events for monitored traffic to the Secure Firewall Management Center database, regardless of the logging configuration of the rule or default action that later handles the connection.
The Do Not Decrypt action passes encrypted traffic for evaluation by the access control policy’s rules and default action. Because some access control rule conditions require unencrypted traffic, this traffic might match fewer rules. The system cannot perform deep inspection on encrypted traffic, such as intrusion or file inspection.
Typical reasons for a Do Not Decrypt rule action include:
When decrypting TLS/SSL traffic is prohibited by law.
Sites you know you can trust.
Sites you can disrupt by inspecting traffic (such as Windows Update).
To view the values of TLS/SSL fields using connection events. (You do not need to decrypt traffic to view connection event fields.) For more information, see Requirements for Populating Connection Event Fields in the Cisco Secure Firewall Management Center Administration Guide.
For more information, see Default Handling Options for Undecryptable Traffic
You can optionally choose to include categories in your SSL policies. These categories, also referred to as URL filtering, are updated by the Cisco Talos intelligence group. Updates are based on machine learning and human analysis according to content that is retrievable from the website destination and sometimes from its hosting and registration information. Categorization is not based on the declared company vertical, intent, or security. While we strive to continuously update and improve URL filtering categories, it is not an exact science. Some websites are not categorized at all and it's possible some websites might be improperly categorized.
Avoid overusing categories in do not decrypt rules to avoid decrypting traffic without a reason; for example, the Health and Medicine category includes the WebMD website, which does not threaten patient privacy.
Following is a sample decryption policy that can prevent decryption for websites in the Health and Medicine category but allow decryption for WebMD and everything else. General information about decryption rules can be found in Guidelines for Using TLS/SSL Decryption.
Note |
Don't confuse URL filtering with application detection, which relies on reading some of the packet from a website to determine more specifically what it is (for example, Facebook Message or Salesforce). For more information, see Best Practices for Configuring Application Control. |
The system provides the following TLS/SSL rule actions for traffic you do not want to pass through the system:
Block to terminate the connection, resulting in an error in the client browser.
The error message does not indicate the site was blocked due to policy. Instead, errors might indicate that there are no common encryption algorithms. It is not obvious from this message that you blocked the connection on purpose.
Block with reset to terminate and reset the connection, resulting in an error in the client browser.
The error indicates the connection was reset but does not indicate why.
Tip |
You cannot use the Block or Block with reset action in a passive or inline (tap mode) deployment because the device does not directly inspect the traffic. If you create
a rule with the Block or Block with reset action that contains passive or inline (tap mode) interfaces within a security zone condition, the policy editor displays
a warning ( |
The Decrypt - Known Key and Decrypt - Resign actions decrypt encrypted traffic. The system inspects decrypted traffic with access control. Access control rules handle decrypted and unencrypted traffic identically — you can inspect it for discovery data as well as detect and block intrusions, prohibited files, and malware. The system reencrypts allowed traffic before passing it to its destination.
We recommend you use a certificate from a trusted Certificate Authority (CA) to decrypt traffic. This prevents Invalid Issuer from being displayed in the SSL Certificate Status column in connection events.
For more information about adding trusted objects, see Trusted Certificate Authority Objects.
Related topic: TLS 1.3 Decryption Best Practices.
The following topics discuss how to monitor the status of TLS/SSL
If a system under load is working well, you should see large counts for the following counters. Because there are 2 sides to the tracker process per connection, you can see these counters increase by 2 per connection. The PRIV_KEY_RECV and SECU_PARAM_RECV counters are the most important, and are highlighted. The CONTEXT_CREATED and CONTEXT_DESTROYED counters relate to the allocation of cryptographic chip memory.
) next to the rule.
> show counters
Protocol Counter Value Context
SSLENC CONTEXT_CREATED 258225 Summary
SSLENC CONTEXT_DESTROYED 258225 Summary
TLS_TRK OPEN_SERVER_SESSION 258225 Summary
TLS_TRK OPEN_CLIENT_SESSION 258225 Summary
TLS_TRK UPSTREAM_CLOSE 516450 Summary
TLS_TRK DOWNSTREAM_CLOSE 516450 Summary
TLS_TRK FREE_SESSION 516450 Summary
TLS_TRK CACHE_FREE 516450 Summary
TLS_TRK PRIV_KEY_RECV 258225 Summary
TLS_TRK NO_KEY_ENABLE 258225 Summary
TLS_TRK SECU_PARAM_RECV 516446 Summary
TLS_TRK DECRYPTED_ALERT 258222 Summary
TLS_TRK DECRYPTED_APPLICATION 33568976 Summary
TLS_TRK ALERT_RX_CNT 258222 Summary
TLS_TRK ALERT_RX_WARNING_ALERT 258222 Summary
TLS_TRK ALERT_RX_CLOSE_NOTIFY 258222 Summary
TCP_PRX OPEN_SESSION 516450 Summary
TCP_PRX FREE_SESSION 516450 Summary
TCP_PRX UPSTREAM_CLOSE 516450 Summary
TCP_PRX DOWNSTREAM_CLOSE 516450 Summary
TCP_PRX FREE_CONN 258222 Summary
TCP_PRX SERVER_CLEAN_UP 258222 Summary
TCP_PRX CLIENT_CLEAN_UP 258222 Summary
We implemented the following counters according to the TLS 1.2 specification. FATAL or BAD alerts could indicate issues; however, ALERT_RX_CLOSE_NOTIFY is normal.
For details, see RFC 5246 section 7.2.
TLS_TRK ALERT_RX_CNT 311 Summary
TLS_TRK ALERT_TX_CNT 2 Summary
TLS_TRK ALERT_TX_IN_HANDSHAKE_CNT 2 Summary
TLS_TRK ALERT_RX_IN_HANDSHAKE_CNT 2 Summary
TLS_TRK ALERT_RX_WARNING_ALERT 308 Summary
TLS_TRK ALERT_RX_FATAL_ALERT 3 Summary
TLS_TRK ALERT_TX_FATAL_ALERT 2 Summary
TLS_TRK ALERT_RX_CLOSE_NOTIFY 308 Summary
TLS_TRK ALERT_RX_BAD_RECORD_MAC 2 Summary
TLS_TRK ALERT_TX_BAD_RECORD_MAC 2 Summary
TLS_TRK ALERT_RX_BAD_CERTIFICATE 1 SummaryThese counters indicate system errors. These counts should be low on a healthy system. The BY_PASS counters indicate packets that have been passed directly to or from the inspection engine (Snort) process (which runs in software) without decryption. The following example lists some of the bad counters.
Counters with a value of 0 are not displayed. To view a complete list of counters, use the command show counters description | include TLS_TRK
> show counters
Protocol Counter Value Context
TCP_PRX BYPASS_NOT_ENOUGH_MEM 2134 Summary
TLS_TRK CLOSED_WITH_INBOUND_PACKET 2 Summary
TLS_TRK ENC_FAIL 82 Summary
TLS_TRK DEC_FAIL 211 Summary
TLS_TRK DEC_CKE_FAIL 43194 Summary
TLS_TRK ENC_CB_FAIL 4335 Summary
TLS_TRK DEC_CB_FAIL 909 Summary
TLS_TRK DEC_CKE_CB_FAIL 818 Summary
TLS_TRK RECORD_PARSE_ERR 123 Summary
TLS_TRK IN_ERROR 44948 Summary
TLS_TRK ERROR_UPSTREAM_RECORD 43194 Summary
TLS_TRK INVALID_CONTENT_TYPE 123 Summary
TLS_TRK DOWNSTREAM_REC_CHK_ERROR 123 Summary
TLS_TRK DECRYPT_FAIL 43194 Summary
TLS_TRK UPSTREAM_BY_PASS 127 Summary
TLS_TRK DOWNSTREAM_BY_PASS 127 Summary
The fatal counters indicate serious errors. These counters should be at or near 0 on a healthy system. The following example lists the fatal counters.
> show counters
Protocol Counter Value Context
CRYPTO RING_FULL 1 Summary
CRYPTO ACCELERATOR_CORE_TIMEOUT 1 Summary
CRYPTO ACCELERATOR_RESET 1 Summary
CRYPTO RSA_PRIVATE_DECRYPT_FAILED 1 Summary
The RING_FULL counter is not a fatal counter, but indicates how often the system overloaded the cryptographic chip. The ACCELERATOR_RESET counter is the number of times the TLS crypto acceleration process failed unexpectedly, which also causes the failure of pending operations, which are the numbers you see in ACCELERATOR_CORE_TIMEOUT and RSA_PRIVATE_DECRYPT_FAILED.
If you have persistent problems, disable TLS crypto acceleration ( or config hwCrypto disable ) and work with Cisco TAC to resolve the issues.
Note |
You can do additional troubleshooting using the show snort tls-offload and debug snort tls-offload commands. Use the clear snort tls-offload command to reset the counters displayed in the show snort tls-offload command to zero. |
The following topics discuss how to troubleshoot TLS/SSL rules.
TLS/SSL oversubscription is a state where a managed device is overloaded with TLS/SSL traffic. Any managed device can experience TLS/SSL oversubscription but only managed devices that support TLS crypto acceleration provide a configurable way to handle it.
When a managed device with TLS crypto acceleration enabled is oversubscribed, any packet received by the managed device is acted on according to the setting for Handshake Errors in the SSL policy's Undecryptable Actions:
Inherit default action
Do not decrypt
Block
Block with reset
If the setting for Handshake Errors in the SSL policy's Undecryptable Actions is Do Not decrypt and the associated access control policy is configured to inspect the traffic, inspection occurs; decryption does not occur.
If your managed device has TLS crypto acceleration enabled, you can view connection events to determine whether or not the devices are experiencing SSL oversubscription. You must add at least the SSL Flow Flags event to the table view of connection events.
Configure an SSL policy with a setting for Handshake Errors on Undecryptable Actions page.
For more information, see Set Default Handling for Undecryptable Traffic.
Enable logging for your SSL rules as discussed in the section on logging decryptable connections in TLS/SSL rules in the Secure Firewall Management Center and Threat Defense Management Network Administration guide.
|
Step 1 |
If you haven't done so already, log in to the management center. |
||||||
|
Step 2 |
Click . |
||||||
|
Step 3 |
Click Table View of Connection Events. |
||||||
|
Step 4 |
Click x on any column in the connection events table to add additional columns for at least SSL Flow Flags and SSL Flow Messages.
The following example shows adding the SSL Actual Action, SSL Flow Error, SSL Flow Flags, SSL Flow Messages, SSL Policy, and SSL Rule columns to the table of connection events. (Look in the Disabled Columns section of the dialog box.)  The columns are added in the order discussed in Connection and Security Intelligence Event Fields in the Cisco Secure Firewall Management Center Administration Guide . |
||||||
|
Step 5 |
Click Apply. |
||||||
|
Step 6 |
If TLS/SSL oversubscription is occurring, log in to the managed device and enter any of the following commands:
|
Some applications use the TLS heartbeat extension to the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols defined by RFC6520. TLS heartbeat provides a way to confirm the connection is still alive—either the client or server sends a specified number of bytes of data and requests the other party echo the response. If this is successful, encrypted data is sent.
When a managed device with TLS crypto acceleration enabled encounters a packet that uses the TLS heartbeat extension, the managed device takes the action specified by the setting for Decryption Errors in the SSL policy's Undecryptable Actions:
Block
Block with reset
If your managed device has TLS crypto acceleration enabled, you can view connection events to determine whether or not the devices are seeing traffic with the TLS heartbeat extension. You must add at least the SSL Flow Messages event to the table view of connection events.
SSL heartbeat is indicated by the value of HEARTBEAT in the SSL Flow Messages column in the table view of connection events. To determine if applications in your network use SSL heartbeat, first perform the following tasks:
Configure an SSL policy with a setting for Decryption Errors on Undecryptable Actions page.
For more information, see Set Default Handling for Undecryptable Traffic.
Enable logging for your SSL rules as discussed in Secure Firewall Management Center and Threat Defense Management Network Administration.
|
Step 1 |
If you haven't done so already, log in to the management center. |
|
Step 2 |
Click . |
|
Step 3 |
Click Table View of Connection Events. |
|
Step 4 |
Click x on any column in the connection events table to add additional columns for at least SSL Flow Flags and SSL Flow Messages.
The following example shows adding the SSL Actual Action, SSL Flow Error, SSL Flow Flags, SSL Flow Messages, SSL Policy, and SSL Rule columns to the table of connection events.
The columns are added in the order discussed in Connection and Security Intelligence Event Fields in the Cisco Secure Firewall Management Center Administration Guide . |
|
Step 5 |
Click Apply. |
|
Step 6 |
If applications in your network use SSL heartbeat, see TLS/SSL Rule Guidelines and Limitations. |
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 TLS/SSL rule with a Decrypt - Resign action, when the application receives a resigned certificate from a managed device, validation fails and the connection is aborted.
To confirm that TLS/SSL pinning is occurring, attempt to log in to a mobile application like Facebook. If a network connection error is displayed, log in using a web browser. (For example, you cannot log in to a Facebook mobile application but can log in to Facebook using Safari or Chrome.) You can use Firepower Management Center connection events as further proof of TLS/SSL pinning
Note |
TLS/SSL pinning is not limited to mobile applications. |
If applications in your network use SSL pinning, see TLS/SSL Certificate Pinning Guidelines.
You can view connection events to determine whether or not the devices are experiencing SSL pinning. You must add at least the SSL Flow Flags and SSL Flow Messages columns to the table view of connection events.
Enable logging for your TLS/SSL rules as discussed in the section on logging decryptable connections in TLS/SSL rules in the Secure Firewall Management Center and Threat Defense Management Network Administration guide.
Log in to a mobile application like Facebook; if a network connection error displays, log in to Facebook using Chrome or Safari. If you can log in using a web browser but not the native application, SSL pinning is likely occurring.
|
Step 1 |
If you haven't done so already, log in to the management center. |
|
Step 2 |
Click . |
|
Step 3 |
Click Table View of Connection Events. |
|
Step 4 |
Click x on any column in the connection events table to add additional columns for at least SSL Flow Flags and SSL Flow Messages.
The following example shows adding the SSL Actual Action, SSL Flow Error, SSL Flow Flags, SSL Flow Messages, SSL Policy, and SSL Rule columns to the table of connection events. The columns are added in the order discussed in the section on connection and security intelligence event fields in the Secure Firewall Management Center and Threat Defense Management Network Administration guide. |
|
Step 5 |
Click Apply. |
|
Step 6 |
The following paragraphs discuss how you can identify SSL pinning behavior. |
|
Step 7 |
If you determine that applications in your network use SSL pinning, see TLS/SSL Rule Guidelines and Limitations. |
You can use TLS/SSL connection events to confirm TLS/SSL pinning is occurring by looking for any of the following:
Applications that send an SSL ALERT Message as soon as the client receives the SERVER_HELLO, SERVER_CERTIFICATE, SERVER_HELLO_DONE message from the server, followed by a TCP Reset, exhibit the following symptoms. (The alert, Unknown CA (48), can be viewed using a packet capture.)
The SSL Flow Flags column displays ALERT_SEEN but not APP_DATA_C2S or APP_DATA_S2C.
If your managed device has SSL hardware acceleration enabled, the SSL Flow Messages column typically displays: CLIENT_ALERT, CLIENT_HELLO, SERVER_HELLO, SERVER_CERTIFICATE, SERVER_KEY_EXCHANGE, SERVER_HELLO_DONE.
If your managed device doesn't support SSL hardware acceleration or if the feature is disabled, the SSL Flow Messages column typically displays: CLIENT_HELLO, SERVER_HELLO, SERVER_CERTIFICATE, SERVER_KEY_EXCHANGE, SERVER_HELLO_DONE.
Success is displayed in the SSL Flow Error column.
Applications that send no alerts but instead send TCP Reset after the SSL handshake is finished exhibit the following symptoms:
The SSL Flow Flags column does not display ALERT_SEEN, APP_DATA_C2S, or APP_DATA_S2C.
If your managed device has SSL hardware acceleration enabled, the SSL Flow Messages column typically displays: CLIENT_HELLO, SERVER_HELLO, SERVER_CERTIFICATE, SERVER_KEY_EXCHANGE, SERVER_HELLO_DONE, CLIENT_KEY_EXCHANGE, CLIENT_CHANGE_CIPHER_SPEC, CLIENT_FINISHED, SERVER_CHANGE_CIPHER_SPEC, SERVER_FINISHED.
If your managed device doesn't support SSL hardware acceleration or if the feature is disabled, the SSL Flow Messages column typically displays: CLIENT_HELLO, SERVER_HELLO, SERVER_CERTIFICATE, SERVER_KEY_EXCHANGE, SERVER_HELLO_DONE, CLIENT_KEY_EXCHANGE, CLIENT_CHANGE_CIPHER_SPEC, CLIENT_FINISHED,SERVER_CHANGE_CIPHER_SPEC, SERVER_FINISHED.
Success is displayed in the SSL Flow Error column.
You can view connection events to determine whether or not the devices are experiencing unknown certificate authorities, bad certificates, or unknown certificates. This procedure can also be used if a TLS/SSL certificate has been pinned. You must add at least the SSL Flow Flags and SSL Flow Messages columns to the table view of connection events.
Set up a TLS/SSL rule.
Enable logging for your TLS/SSL rules as discussed in the section on logging decryptable connections in TLS/SSL rules in the Secure Firewall Management Center and Threat Defense Management Network Administration guide.
|
Step 1 |
If you haven't done so already, log in to the management center. |
||||||||
|
Step 2 |
Click . |
||||||||
|
Step 3 |
Click Table View of Connection Events. |
||||||||
|
Step 4 |
Click x on any column in the connection events table to add additional columns for at least SSL Flow Flags and SSL Flow Messages.
The following example shows adding the SSL Actual Action, SSL Flow Error, SSL Flow Flags, SSL Flow Messages, SSL Policy, and SSL Rule columns to the table of connection events. The columns are added in the order discussed in the section on connection and security intelligence event fields in the Secure Firewall Management Center and Threat Defense Management Network Administration guide. |
||||||||
|
Step 5 |
Click Apply. |
||||||||
|
Step 6 |
The following table discusses how you can determine if a certificate or certificate authority is bad or missing.
|
This topic discusses actions you must take if you see the following error when saving a TLS/SSL rule that has cipher suite conditions:
Traffic cannot match this rule; none of your selected cipher suites contain a signature
algorithm that the resigning CA's signature algorithmThe error indicates that one or more of the cipher suites you chose for the TLS/SSL rule condition are incompatible with the certificate used in the TLS/SSL rule. To resolve the issue, you must have access to the certificate you're using.
Note |
The tasks in this topic assume knowledge of how TLS/SSL encryption works. |
|
Step 1 |
When you attempt to save an SSL rule with either Decrypt - Resign or Decrypt - Known Key with specified cipher suites, the following error is displayed: Example: |
|
Step 2 |
Locate the certificate you're using to decrypt traffic and, if necessary, copy the certificate to a system that can run openssl commands. |
|
Step 3 |
Run the following command to display the signature algorithm used by the certificate: openssl x509 -in CertificateName -text -noout The first few lines of output are displayed similar to the following: |
|
Step 4 |
The Signature algorithm tells you the following:
|
|
Step 5 |
Search a resource such as OpenSSL at University of Utah for cipher suites that match those values. The cipher suite must be in RFC format. |
|
Step 6 |
If necessary, translate the OpenSSL name to an RFC name that the Firepower Management System uses. https://testssl.sh site.
|
|
Step 7 |
The previous example, ecdsa-with-SHA256 , can be found in the Modern Compatibility List on the Mozilla wiki. |
|
Step 8 |
Add the preceding cipher suites to your TLS/SSL rule. |
Feedback