Understanding Traffic Decryption

The following topics provide an overview of Transport Layer Security/Secure Sockets Layer (TLS/SSL) inspection, discuss the prerequisites for TLS/SSL inspection configuration, and detail deployment scenarios.


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 FMC configuration option is Policies > Access Control > SSL, 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?.

Traffic Decryption Explained

By default, the Firepower System cannot inspect traffic encrypted with the Secure Socket Layer (SSL) protocol or its successor, the Transport Layer Security (TLS) protocol. TLS/SSL inspection enables you to either block encrypted traffic without inspecting it, or inspect encrypted or decrypted traffic with access control. As the system handles encrypted sessions, it logs details about the traffic. The combination of inspecting encrypted traffic and analyzing encrypted session data allows greater awareness and control of the encrypted applications and traffic in your network.

TLS/SSL inspection is a policy-based feature. In the Firepower System, an access control policy is a main configuration that invokes subpolicies and other configurations, including an SSL policy. If you associate an SSL policy with access control, the system uses that SSL policy to handle encrypted sessions before it evaluates them with access control rules. If you do not configure TLS/SSL inspection, or your devices do not support it, access control rules handle all encrypted traffic.

Access control rules also handle encrypted traffic when your TLS/SSL inspection configuration allows it to pass. However, some access control rule conditions require unencrypted traffic, so encrypted traffic might match fewer rules. Also, by default, the system disables intrusion and file inspection of encrypted payloads. This helps reduce false positives and improves performance when an encrypted connection matches an access control rule that has intrusion and file inspection configured.

If the system detects a TLS/SSL handshake over a TCP connection, it determines whether it can decrypt the detected traffic. If it cannot, it applies a configured action:

  • Block the encrypted traffic

  • Block the encrypted traffic and reset the TCP connection

  • Not decrypt the encrypted traffic

If the system cannot decrypt the traffic, it blocks the traffic without further inspection, evaluates undecrypted traffic with access control; otherwise, the system decrypts it using one of the following methods:

  • Decrypt with a known private key. When an external host initiates a TLS/SSL handshake with a server on your network, the system matches the exchanged server certificate with a server certificate previously uploaded to the system. It then uses the uploaded private key to decrypt the traffic.

  • Decrypt by resigning the server certificate. When a host on your network initiates a TLS/SSL handshake with an external server, the system resigns the exchanged server certificate with a previously uploaded certificate authority (CA) certificate. It then uses the uploaded private key to decrypt the traffic.


Note

The Firepower System does not support mutual authentication; that is, you cannot upload a client certificate to the FMC and use it for either Decrypt - Resign or Decrypt - Known Key TLS/SSL rule actions. For more information, see Decrypt and Resign (Outgoing Traffic). and Known Key Decryption (Incoming Traffic).

Decrypted traffic is subject to the same traffic handling and analysis as originally unencrypted traffic: network, reputation, and user-based access control; intrusion detection and prevention; Cisco Advanced Malware Protection (Cisco AMP); and discovery. If the system does not block the decrypted traffic post-analysis, it re-encrypts the traffic before passing it to the destination host.


Note

Set up decrypt rules only if your managed device handles encrypted traffic. Decryption rules require processing overhead that can impact performance.

The Firepower System does not currently support TLS version 1.3 encryption or decryption. When users visit a web site that negotiates TLS 1.3 encryption, users might see errors similar to the following in their web browser:

  • ERR_SSL_PROTOCOL_ERROR

  • SEC_ERROR_BAD_SIGNATURE

  • ERR_SSL_VERSION_INTERFERENCE

For more information about how to control this behavior, contact Cisco TAC.

If you set the value of TCP maximum segment size (MSS) using FlexConfig, the observed MSS could be less than your setting. For more information, see About the TCP MSS.

TLS/SSL Handshake Processing

In this documentation, the term TLS/SSL handshake represents the two-way handshake that initiates encrypted sessions in both the SSL protocol and its successor protocol, TLS.

In a passive deployment, the Firepower System observes a copy of the handshake, but does not process the actual handshake.

In an inline deployment, the Firepower System processes the TLS/SSL handshake, potentially modifying the ClientHello message and acting as a TCP proxy server for the session.

After the client establishes a TCP connection with the server (after it successfully completes the TCP three-way handshake), the managed device monitors the TCP session for any attempt to initiate an encrypted session. The TLS/SSL handshake establishes an encrypted session via the exchange of specialized packets between client and server. In the SSL and TLS protocols, these specialized packets are called handshake messages. The handshake messages communicate which encryption attributes both the client and server support:

  • ClientHello—The client specifies multiple supported values for each encryption attribute.

  • ServerHello—The server specifies a single supported value for each encryption attribute, which determines which encryption method the system uses during the secure session.

Although the data transmitted in the session is encrypted, the handshake messages are not.

After a TLS/SSL handshake completes, the managed device caches encrypted session data, which allows session resumption without requiring the full handshake. The managed device also caches server certificate data, which allows faster handshake processing in subsequent sessions.

ClientHello Message Handling

The client sends the ClientHello message to the server that acts as the packet destination if a secure connection can be established. The client sends the message to initiate the TLS/SSL handshake or in response to a Hello Request message from the destination server.

If you configure TLS/SSL decryption, when a managed device receives a ClientHello message, the system attempts to match the message to TLS/SSL rules that have the Decrypt - Resign action. The match relies on data from the ClientHello message and from cached server certificate data. Possible data includes:

Table 1. Data Availability for TLS/SSL Rule Conditions

TLS/SSL Rule Condition

Data Present In

Zones

ClientHello

Networks

ClientHello

VLAN Tags

ClientHello

Ports

ClientHello

Users

ClientHello

Applications

ClientHello (Server Name Indicator extension)

Categories

ClientHello (Server Name Indicator extension)

Certificate

server Certificate (potentially cached)

Distinguished Names

server Certificate (potentially cached)

Certificate Status

server Certificate (potentially cached)

Cipher Suites

ServerHello

Versions

ServerHello

If the ClientHello message does not match a Decrypt - Resign rule, the system does not modify the message. It then determines whether the message passes access control evaluation (which can include deep inspection). If the message passes, the system transmits it to the destination server.

If the message matches a Decrypt - Resign rule, the system modifies the ClientHello message as follows:

  • Compression methods—Strips the compression_methods element, which specifies the compression methods the client supports. The Firepower System cannot decrypt compressed sessions. This modification reduces the Compressed Session type of undecryptable traffic.

  • Cipher suites—Strips cipher suites from the cipher_suites element if the Firepower System does not support them. If the Firepower System does not support any of the specified cipher suites, the system transmits the original, unmodified element. This modification reduces the Unknown Cipher Suite and Unsupported Cipher Suite types of undecryptable traffic.

  • Session identifiers—Strips any value from the Session Identifier element and the SessionTicket extension that does not match cached session data. If a ClientHello value matches cached data, an interrupted session can resume without the client and server performing the full TLS/SSL handshake. This modification increases the chances of session resumption and reduces the Session Not Cached type of undecryptable traffic.

  • Elliptic curves—Strips elliptic curves from the Supported Elliptic Curves extension if the Firepower System does not support them. If the Firepower System does not support any of the specified elliptic curves, the managed device removes the extension and strips any related cipher suites from the cipher_suites element.

  • ALPN extensions—The Firepower System strips the Application-Layer Protocol Negotiation (ALPN) extension, which is used in protocols the system does not support (for example, the SPDY and HTTP/2 protocols) only if the message matches an SSL rule associated with content restriction features. For more information about content restriction, see About Content Restriction.

    If content restriction is not being enforced, you can use the system support ssl-client-hello-enabled ALPN true command to strip the ALPN extension. Stripping the ALPN extension increases the likelihood of traffic decryption and inspection.

  • Other Extensions—Strips the Extended Master Secret, Next Protocol Negotiation (NPN), and TLS Channel IDs extensions.

    SSL rules with a Decrypt - Resign or Decrypt - Known Key action now natively support the Extended Master Secret (EMS) extension during ClientHello negotiation, enabling more secure communications. The EMS extension is defined by RFC 7627.


Note

The system performs these ClientHello modifications by default. If your SSL policy is configured correctly, this default behavior results in more frequent decryption of traffic. To tune the default behavior for your individual network, contact Cisco TAC.


Note

Use the Cipher Suite and Version rule conditions only in rules with either the Block or Block with reset rule actions. The use of these conditions in rules with other rule actions can interfere with the system's ClientHello processing, resulting in unpredictable performance.

After the system modifies the ClientHello message, it determines whether the message passes access control evaluation (which can include deep inspection). If the message passes, the system transmits it to the destination server.

Direct communication between the client and server is no longer possible during the TLS/SSL handshake, because after message modification the Message Authentication Codes (MACs) computed by the client and server no longer match. For all subsequent handshake messages (and for the encrypted session once established), the managed device acts as a man-in-the-middle (MITM). It creates two TLS/SSL sessions, one between client and managed device, one between managed device and server. As a result, each session contains different cryptographic session details.


Note

The cipher suites that the Firepower System can decrypt are frequently updated and do not correspond directly to the cipher suites you can use in TLS/SSL rule conditions. For the current list of decryptable cipher suites, contact Cisco TAC.

ServerHello and Server Certificate Message Handling

The ServerHello message is the response to a ClientHello message in a successful TLS/SSL handshake.

After a managed device processes a ClientHello message and transmits it to the destination server, the server determines whether it supports the decryption attributes the client specified in the message. If it does not support those attributes, the server sends a handshake failure alert to the client. If it supports those attributes, the server sends the ServerHello message. If the agreed-upon key exchange method uses certificates for authentication, the server Certificate message immediately follows the ServerHello message.

When the managed device receives these messsages, it attempts to match them with TLS/SSL rules. These messages contain information that was absent from either the ClientHello message or the session data cache. Specifically, the system can potentially match these messages on Distinguished Names, Certificate Status, Cipher Suites, and Versions conditions.

If the messages do not match any TLS/SSL rules, the managed device performs the default action for the SSL policy. For more information, see SSL Policy Default Actions.

If the messages match an SSL rule, the managed device continues as appropriate:

Action: Monitor
The TLS/SSL handshake continues to completion. The managed device tracks and logs but does not decrypt encrypted traffic.
Action: Block or Block with Reset

The managed device blocks the TLS/SSL session. If appropriate, it also resets the TCP connection.

Action: Do Not Decrypt

The TLS/SSL handshake continues to completion. The managed device does not decrypt the application data exchanged during the TLS/SSL session.

Action: Decrypt - Known Key

The managed device attempts to match the server certificate data to an Internal Certificate object previously imported into the Firepower Management Center. Because you cannot generate an Internal Certificate object, and you must possess its private key, we assume you own the server on which you're using known key decryption.

If the certificate matches a known certificate, the TLS/SSL handshake continues to completion. The managed device uses the uploaded private key to decrypt and reencrypt the application data exchanged during the TLS/SSL session.

If the server changes its certificate between the initial connection with the client and subsequent connections, you must import the new server certificate in the Firepower Management Center for future connections to be decrypted.


Note

Because the Firepower System does not support the Extended Master Secret extension defined by RFC 7627, you must disable this extension on the server for which you're decrypting with a known key; otherwise, the connection is reset during decryption, resulting in connection errors.

Action: Decrypt - Resign

The managed device processes the server certificate message and re-signs the server certificate with the previously imported or generated certificate authority (CA). The TLS/SSL handshake continues to completion. The managed device then uses the uploaded private key to decrypt and reencrypt the application data exchanged during the TLS/SSL session.


Note

The Firepower System does not support mutual authentication; that is, you cannot upload a client certificate to the FMC and use it for either Decrypt - Resign or Decrypt - Known Key TLS/SSL rule actions. For more information, see Decrypt and Resign (Outgoing Traffic). and Known Key Decryption (Incoming Traffic).

TLS/SSL Best Practices

This section discusses information you should keep in mind when creating your decryption policies and 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 FMC configuration option is Policies > Access Control > SSL, 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?.

The Case for Decryption

Only decrypted traffic takes advantage of the Firepower System's threat defense and policy enforcement features. Traffic that is encrypted when it passes through the Firepower System can be allowed or blocked only but it cannot be subjected to deep inspection or the full range of policy enforcement (such as intrusion prevention).

All encrypted connections are:

  • Sent through the TLS/SSL decryption policy to determine if they should be decrypted or blocked.

    You can also configure TLS/SSL decryption rules to block encrypted traffic of types you know you do not want on your network, such as traffic that uses the nonsecure SSL protocol or traffic with an expired or invalid certificate.

  • Any unblocked connections, whether or not decrypted, then go through the access control policy for a final allow or block decision.

Keep in mind that decrypting and then re-encrypting traffic adds a processing load on the device, which can reduce overall system performance.

In summary:

  • Encrypted traffic can be allowed or blocked by policy; encrypted traffic cannot be inspected

  • Decrypted traffic is subject to threat defense and policy enforcement; decrypted traffic can be allowed or blocked by policy

When to Decrypt Traffic, When Not to Decrypt

This section provides guidelines on when you should decrypt traffic and when you should allow it to pass through the firewall encrypted.

When not to decrypt traffic

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

If you elect to bypass decryption for certain types of traffic, no processing is done on the traffic. The encrypted traffic is first evaluated by SSL policy and then proceeds to the access control policy, where a final allow or block decision is made. 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

SSL policies provide a Do Not Decrypt action for this traffic; for more information, see TLS/SSL Rule Do Not Decrypt Action.


Note

Neither TLS server identity discovery nor the decryption of TLS 1.3 traffic is supported on 8000 Series devices.


Note

The related information links at the end of this topic explain how some aspects of rule evaluation work. Conditions such as URL and application filtering have limitations with respect to encrypted traffic. Make sure you understand those limitations.

When to decrypt traffic

All encrypted traffic must be decrypted to take advantage of the Firepower System's threat protection and policy enforcement features. To the extent your managed device allows traffic to be decrypted (subject to its memory and processing power), you should decrypt traffic that is not protected by law or regulation. If you must decide what traffic to decrypt, base your decision on the risk of allowing the traffic on your network. The Firepower System provides a flexible framework for classifying traffic using rule conditions, which include URL reputation, cipher suite, protocol, and many other factors.

The Firepower System provides two methods of decryption, which are discussed in the following sections.

Decrypt and Resign (Outgoing Traffic)

The Decrypt - Resign TLS/SSL rule action enables the Firepower System to act as a man in the middle, intercepting, decrypting, and (if the traffic is allowed) inspecting, and re-encrypting it. The Decrypt - Resign rule action is used with outgoing traffic; that is, the destination server is outside your protected network.

The FTD device negotiates with the client using an internal Certificate Authority (CA) object specified in the rule and builds an SSL tunnel between the client and the FTD device. At the same time, the device connects to the destination web site and creates an SSL tunnel between the server and the FTD device.

Thus, the client sees the CA certificate configured for the SSL decryption rule instead of the certificate from the destination server. The client must trust the certificate to complete the connection. The FTD device then performs decryption/re-encryption in both directions for traffic between the client and the destination server.

Prerequisite

To use the Decrypt - Resign rule action, you must create an internal CA object using a CA file and paired private key file. You can generate a CA and private key in the Firepower System if you don't already have them.


Note

The Firepower System does not support mutual authentication; that is, you cannot upload a client certificate to the FMC and use it for either Decrypt - Resign or Decrypt - Known Key TLS/SSL rule actions. For more information, see Decrypt and Resign (Outgoing Traffic). and Known Key Decryption (Incoming Traffic).

Known Key Decryption (Incoming Traffic)

The Decrypt - Known Key TLS/SSL rule action uses a server's private key to decrypt traffic. The Decrypt - Known Key rule action is used with incoming traffic; that is, the destination server is inside your protected network.

The main purpose of decrypting with a known key is to protect your servers from external attacks.

Prerequisite

To use the Decrypt - Known Key rule action, you must create an internal certificate object using the server’s certificate file and paired private key file.


Note

The Firepower System does not support mutual authentication; that is, you cannot upload a client certificate to the FMC and use it for either Decrypt - Resign or Decrypt - Known Key TLS/SSL rule actions. For more information, see Decrypt and Resign (Outgoing Traffic). and Known Key Decryption (Incoming Traffic).

TLS/SSL Rule Examples

The following sections provide examples of setting up recommended TLS/SSL rules.

Block Nonsecure Protocols

This example shows how to block TLS and SSL protocols on your network that are no longer considered secure, such as TLS 1.0, TLS 1.1, and SSLv3.

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

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

  • Because the Firepower System considers SSLv2 as undecryptable, you can block it using the Undecryptable Actions on the SSL policy.

Procedure

Step 1

Log in to the Firepower Management System if you have not already done so.

Step 2

Click Policies > Access Control > SSL.

Step 3

Add or edit an SSL policy.

Step 4

Click Add Rule.

Step 5

In the Name field, enter a name for the rule.

Step 6

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

Step 7

Click Version page.

Step 8

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

The following figure shows an example.

Step 9

Choose other rule conditions as needed.

Step 10

Save the rule.

Step 11

On the SSL policy page, click Undecryptable Actions.

Step 12

From the SSLv2 Session list, click Block or Block with reset. The following figure shows an example.

Step 13

Click Save.

Step 14

Because this is a specific rule, order it earlier in your policy than more general rules such as application-matching rules.
What to do next

TLS/SSL Rule Components

Each TLS/SSL rule has the following components.

State

By default, rules are enabled. If you disable a rule, the system does not use it to evaluate network traffic, and stops generating warnings and errors for that rule.

Position

Rules in an SSL policy are numbered, starting at 1. The system matches traffic to rules in top-down order by ascending rule number. With the exception of Monitor rules, the first rule that traffic matches is the rule that handles that traffic.

Conditions

Conditions specify the specific traffic the rule handles. Conditions can match traffic by security zone, network or geographical location, VLAN, port, application, requested URL, user, certificate, certificate subject or issuer, certificate status, cipher suite, or encryption protocol version. The use of conditions can depend on target device licenses.

Action

A rule’s action determines how the system handles matching traffic. You can monitor, allow, block, or decrypt encrypted matching traffic. Decrypted and allowed encrypted traffic is subject to further inspection. Note that the system does not perform inspection on blocked encrypted traffic.

Logging

A rule’s logging settings govern the records the system keeps of the traffic it handles. You can keep a record of traffic that matches a rule. You can log a connection when the system blocks an encrypted session or allows it to pass without decryption, according to the settings in an SSL policy. 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. You can log connections to the Firepower Management Center database, as well as to the system log (syslog) or to an SNMP trap server.

For more information about logging, see Best Practices for Connection Logging.


Tip
Properly creating and ordering TLS/SSL rules is a complex task. If you do not plan your policy carefully, rules can preempt other rules, require additional licenses, or contain invalid configurations. To help ensure that the system handles traffic as you expect, the SSL policy interface has a robust warning and error feedback system for rules.

TLS/SSL Rule Order Evaluation

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 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.

Multi-Rule Example

The following scenario summarizes the ways that SSL rules handle traffic in an inline deployment.

Diagram illustrating how SSL rule actions can evaluate encrypted traffic

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 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.

How to Configure TLS/SSL Policies and Rules

This topic provides a high-level overview of tasks you must complete to configure SSL policies and TLS/SSL rules in those policies to block, monitor, or allow TLS/SSL traffic on your network.

You must be an Admin, Access Admin, or Network Admin to perform this task. You can configure SSL policies on any device type except NGIPSv.

Procedure

  Command or Action Purpose

Step 1

Create an SSL policy.
An SSL policy is a container for one or more rules. To use an SSL policy and its rules for access control, you must later associate the SSL policy with an access control policy. For more information, see See Create Basic SSL Policies.

Step 2

Set a default action for your SSL policy.
The default action is taken when traffic matches no rules defined by the SSL policy. See SSL Policy Default Actions.

Step 3

Specify how undecryptable traffic should be handled.
Traffic can be undecryptable for a number of reasons, including unsecure protocols, uses and unknown cipher suite, or in the event of errors with the handshake or decryption. See Default Handling Options for Undecryptable Traffic.

Step 4

For Decrypt - Known Key (to decrypt inbound traffic to a server in your network) TLS/SSL rules, create an internal certificate object.

The internal certificate object uses your server's certificate and private key. See Internal Certificate Objects.

Step 5

For Decrypt - Resign (to decrypt outbound traffic to a server outside of your network) TLS/SSL rules, create an internal certificate authority (CA) object.

The internal CA object uses a CA and private key. See Internal Certificate Authority Objects.

Step 6

Create your TLS/SSL rules:

Step 7

Associate the SSL policy with an access control policy.
Unless you associate your SSL policy with an access control policy, it has no effect. After you do this, you can choose to allow or block traffic that matches the access control rule and take other actions. See Associating Other Policies with Access Control.

Step 8

Configure your access control rules to allow or block decrypted traffic.
See Access Control Policy Components.

Step 9

Deploy the access control policy to managed devices.
Before your policy can take effect, it must be deployed to managed devices. See Deploy Configuration Changes.

TLS/SSL Inspection Appliance Deployment Scenarios

This section presents several scenarios in which the Life Insurance Example, Inc. life insurance company (LifeIns) uses SSL inspection on encrypted traffic to help audit their processes. Based on their business processes, LifeIns plans to deploy:

  • one FTD device in a passive deployment for the Customer Service department

  • one FTD device in an inline deployment for the Underwriting Department

  • one Firepower Management Center to manage both devices

Customer Service Business Processes

LifeIns created a customer-facing website for their customers. LifeIns receives encrypted questions and requests regarding policies from prospective customers through their website and through e-mail. LifeIns’s Customer Service department processes them and returns the requested information within 24 hours. Customer Service wants to expand its incoming contact metrics collection. LifeIns has an established internal audit review for Customer Service.

LifeIns also receives encrypted applications online. The Customer Service department processes the applications within 24 hours before sending the case file to the Underwriting department. Customer Service filters out any obvious false applications sent through the online form, which consumes a fair portion of their time.

Underwriting Business Processes

LifeIns’s underwriters submit encrypted medical information requests online to the Medical Repository Example, LLC medical data repository (MedRepo). MedRepo reviews the requests and transmits the encrypted records to LifeIns within 72 hours. The underwriters subsequently underwrite an application and submit policy and rate decisions. Underwriting wants to expand its metrics collection.

Lately, an unknown source has been sending spoofed responses to LifeIns. Though LifeIns’s underwriters receive training on proper Internet use, LifeIns’s IT department first wants to analyze all encrypted traffic that takes the form of medical responses, then wants to block all spoof attempts.

LifeIns places junior underwriters on six-month training periods. Lately, these underwriters have been incorrectly submitting encrypted medical regulation requests to MedRepo’s customer service department. MedRepo has submitted multiple complaints to LifeIns in response. LifeIns plans on extending their new underwriter training period to also audit underwriter requests to MedRepo.

Traffic Decryption in a Passive Deployment

LifeIns’s business requirements state that Customer Service must:

  • process all requests and applications within 24 hours

  • improve its incoming contact metrics collection process

  • identify and discard incoming false applications

Customer Service does not require additional audit review.

LifeIns plans to passively deploy a Customer Service managed device.


Diagram illustrating a managed device in a passive deployment. External network traffic is routed to the internal destination host, and a copy is sent to the managed device. A Management Center manages the device.

Traffic from an external network goes to LifeIns’s router. The router routes traffic to the Customer Service department, and mirrors a copy of the traffic to the managed device for inspection.

On the managing Firepower Management Center, a user in the access control configures TLS/SSL inspection to:

  • log all encrypted traffic sent to the Customer Service department

  • decrypt encrypted traffic sent using the online application form to Customer Service

  • not decrypt all other encrypted traffic sent to Customer service, including traffic sent using the online request form

The user also configures access control to inspect the decrypted application form traffic for fake application data and log when fake data is detected.

In the following scenarios, the user submits an online form to Customer Service. The user’s browser establishes a TCP connection with the server, then initiates a TLS/SSL handshake. The managed device receives a copy of this traffic. The client and server complete the TLS/SSL handshake, establishing the encrypted session. Based on handshake and connection details, the system logs the connection and acts upon the copy of the encrypted traffic.

Encrypted Traffic Monitoring in a Passive Deployment

For all TLS/SSL-encrypted traffic sent to Customer Service, the managed device logs the connection.


Diagram illustrating the Do Not Decrypt action in a passive deployment. The external host sends encrypted traffic to an internal host. The router routes traffic to the internal host, and a copy to the managed device. The managed device does not decrypt the traffic. It generates a connection event and sends it to the Management Center.

The following steps occur:

  1. The user submits the plain text request (info). The client encrypts this (AaBb) and sends the encrypted traffic to Customer Service.

  2. LifeIns's router receives the encrypted traffic and routes it to the Customer Service department server. It also mirrors a copy to the managed device.

  3. The Customer Service department server receives the encrypted information request (AaBb) and decrypts it to plain text (info).

  4. The managed device does not decrypt the traffic.

    The access control policy continues to process the encrypted traffic and allows it. The device generates a connection event after the session ends.

  5. The Firepower Management Center receives the connection event.

Undecrypted Encrypted Traffic in a Passive Deployment

For all TLS/SSL-encrypted traffic that contains requests about policies, the managed device allows the traffic without decrypting it and logs the connection.


Diagram illustrating the Do Not Decrypt action in a passive deployment. The external host sends encrypted traffic to an internal host. The router routes traffic to the internal host, and a copy to the managed device. The managed device does not decrypt the traffic. It generates a connection event and sends it to the Management Center.

The following steps occur:

  1. The user submits the plain text request (info). The client encrypts this (AaBb) and sends the encrypted traffic to Customer Service.

  2. LifeIns's router receives the encrypted traffic and routes it to the Customer Service department server. It also mirrors a copy to the managed device.

  3. The Customer Service department server receives the encrypted information request (AaBb) and decrypts it to plain text (info).

  4. The managed device does not decrypt the traffic.

    The access control policy continues to process the encrypted traffic and allows it. The device generates a connection event after the session ends.

  5. The Firepower Management Center receives the connection event.

Encrypted Traffic Inspection with a Private Key in a Passive Deployment

For all TLS/SSL-encrypted traffic that contains application form data, the system decrypts the traffic and logs the connection.


Note

In a passive deployment, if traffic is encrypted with either the DHE or ECDHE cipher suite, you cannot decrypt it with a known private key.

For traffic with legitimate application form information, the system logs the connection.


Diagram illustrating the Decrypt - Known Key action in a passive deployment inspecting legitimate traffic. The external host sends encrypted traffic to an internal host. The router routes traffic to the internal host, and a copy to the managed device. The managed device decrypts the traffic using the known private key stored in the internal certificate object. It generates a connection event and sends it to the Management Center. The device inspects the decrypted traffic, does not match it against an access control rule, and stops inspecting it.

The following steps occur:

  1. The user submits the plain text request (form). The client encrypts this (AaBb) and sends the encrypted traffic to Customer Service.

  2. LifeIns's router receives the encrypted traffic and routes it to the Customer Service department server. It also mirrors a copy to the managed device.

  3. The Customer Service department server receives the encrypted information request (AaBb) and decrypts it to plain text (form).

  4. The managed device uses the session key obtained with the uploaded known private key to decrypt the encrypted traffic to plain text (form).

    The access control policy continues to process the decrypted traffic and does not find fake application information. The device generates a connection event after the session ends.

  5. The Firepower Management Center receives a connection event with information about the encrypted and decrypted traffic.

In contrast, if the decrypted traffic contains fake application data, the system logs the connection and the fake data.


Diagram illustrating the Decrypt - Known Key action in a passive deployment inspecting traffic that is not legitimate. The external host sends encrypted traffic to an internal host. The router routes traffic to the internal host, and a copy to the managed device. The managed device decrypts the traffic using the known private key stored in the internal certificate object. It generates a connection event and sends it to the Management Center. The device matches the decrypted traffic against an access control rule, generates a connection event, and sends it to the Management Center.

The following steps occur:

  1. The user submits the plain text request (fake). The client encrypts this (CcDd) and sends the encrypted traffic to Customer Service.

  2. LifeIns's router receives the encrypted traffic and routes it to the Customer Service department server. It also mirrors a copy to the managed device.

  3. The Customer Service department server receives the encrypted information request (CcDd) and decrypts it to plain text (fake).

  4. The managed device uses the session key obtained with the uploaded known private key to decrypt the encrypted traffic to plain text (fake).

    The access control policy continues to process the decrypted traffic and finds fake application information. The device generates an intrusion event. After the session ends, it generates a connection event.

  5. The Firepower Management Center receives a connection event with information about the encrypted and decrypted traffic, and an intrusion event for the fake application data.

Traffic Decryption in an Inline Deployment

LifeIns’s business requirements state that Underwriting must:

  • audit new and junior underwriters, verifying that their information requests to MedRepo comply with all applicable regulations

  • improve its underwriting metrics collection process

  • examine all requests that appear to come from MedRepo, then drop any spoofing attempts

  • drop all improper regulatory requests to MedRepo’s Customer Service department from the Underwriting department

  • not audit senior underwriters

LifeIns plans to deploy a device in an inline deployment for the Underwriting department.


Diagram illustrating a managed device in an inline deployment. External network traffic is routed to the managed device. Traffic that is not blocked is sent to the router, which in turn routes traffic to an internal host. A Management Center manages the device.

Traffic from MedRepo’s network goes to MedRepo’s router. It routes traffic to LifeIns’s network. The managed device receives the traffic, passes allowed traffic to LifeIns’s router, and sends events to the managing Firepower Management Center. LifeIns’s router routes traffic to the destination host.

On the managing Firepower Management Center, a user in the Access Control and SSL Editor custom role configures an SSL access control rule to:

  • log all encrypted traffic sent to the Underwriting department

  • block all encrypted traffic incorrectly sent from LifeIns’s underwriting department to MedRepo’s customer service department

  • decrypt all encrypted traffic sent from MedRepo to LifeIns’s underwriting department, and from LifeIns’s junior underwriters to MedRepo’s requests department

  • not decrypt encrypted traffic sent from the senior underwriters

The user also configures access control to inspect decrypted traffic with a custom intrusion policy and:

  • block decrypted traffic if it contains a spoof attempt, and log the spoof attempt

  • block decrypted traffic that contains information not compliant with regulations, and log the improper information

  • allow all other encrypted and decrypted traffic

The system reencrypts allowed decrypted traffic before sending it to the destination host.

You can also cause the system to decrypt and resign the traffic using a TLS/SSL control rule with the action Decrypt - Resign. If traffic matches the TLS/SSL rule, after the system modifies the ClientHello message, it determines whether the message passes access control evaluation (which can include deep inspection). If the message passes, the system transmits it to the destination server. For more information, see ClientHello Message Handling

In the following scenarios, the user submits information online to a remote server. The user’s browser establishes a TCP connection with the server, then initiates an SSL handshake. The managed device receives this traffic; based on handshake and connection details, the system logs the connection and acts on the traffic. If the system blocks the traffic, it also closes the TCP connection. Otherwise, the client and server complete the SSL handshake, establishing the encrypted session.

Encrypted Traffic Monitoring in an Inline Deployment

For all SSL-encrypted traffic sent to and from the Underwriting department, the system logs the connection.


Diagram illustrating the Do Not Decrypt action in an inline deployment. The internal host sends encrypted traffic to an external host. The router routes traffic, and the inline managed device receives it. The managed device does not decrypt the traffic, passing it to the external network, where it is routed to the external host. The managed device generates a connection event and sends it to the Management Center.

The following steps occur:

  1. The user submits the plain text request (help). The client encrypts this (AaBb) and sends the encrypted traffic to MedRepo’s Requests department server.

  2. LifeIns's router receives the encrypted traffic and routes it to the Requests department server.

  3. The managed device does not decrypt the traffic.

    The access control policy continues to process the encrypted traffic and allows it, then generates a connection event after the session ends.

  4. The external router receives the traffic and routes it to the Requests department server.

  5. The Underwriting department server receives the encrypted information request (AaBb) and decrypts it to plain text (help).

  6. The Firepower Management Center receives the connection event.

Undecrypted Encrypted Traffic in an Inline Deployment

For all TLS/SSL-encrypted traffic originating from the senior underwriters, the managed device allows the traffic without decrypting it and logs the connection.


Diagram illustrating the Do Not Decrypt action in an inline deployment. The internal host sends encrypted traffic to an external host. The router routes traffic, and the inline managed device receives it. The managed device does not decrypt the traffic, passing it to the external network, where it is routed to the external host. The managed device generates a connection event and sends it to the Management Center.

The following steps occur:

  1. The user submits the plain text request (help). The client encrypts this (AaBb) and sends the encrypted traffic to MedRepo’s Requests department server.

  2. LifeIns's router receives the encrypted traffic and routes it to the Requests department server.

  3. The managed device does not decrypt this traffic.

    The access control policy continues to process the encrypted traffic and allows it, then generates a connection event after the session ends.

  4. The external router receives the traffic and routes it to the Requests department server.

  5. The Requests department server receives the encrypted information request (AaBb) and decrypts it to plain text (help).

  6. The Firepower Management Center receives the connection event.

Encrypted Traffic Blocking in an Inline Deployment

For all SMTPS email traffic improperly sent from LifeIns’s underwriting department to MedRepo’s Customer Service department, the system blocks the traffic during the SSL handshake without further inspection and logs the connection.


Diagram illustrating the Block action in an inline deployment. The internal host sends encrypted traffic to an external host. The router routes traffic, and the inline managed device receives it. The managed device blocks the traffic, then generates a connection event and sends it to the Management Center.

The following steps occur:

  1. Having received the request to establish a TLS/SSL handshake from a client’s browser, the Customer Service department server sends the server certificate (cert) as the next step in the TLS/SSL handshake to the LifeIns underwriter.

  2. MedRepo’s router receives the certificate and routes it to the LifeIns underwriter.

  3. The managed device blocks the traffic without further inspection and ends the TCP connection. It generates a connection event.

  4. The internal router does not receive the blocked traffic.

  5. The underwriter does not receive the blocked traffic.

  6. The Firepower Management Center receives the connection event.

Encrypted Traffic Inspection with a Private Key in an Inline Deployment

For all TLS/SSL-encrypted traffic sent from MedRepo to LifeIns’s underwriting department, the system uses an uploaded server private key to obtain session keys, then decrypts the traffic and logs the connection. Legitimate traffic is allowed and reencrypted before being sent to the Underwriting department.


Diagram illustrating the Decrypt - Known Key action in an inline deployment inspecting legitimate traffic. The external host sends encrypted traffic to an internal host. The router routes traffic, and the inline managed device receives it. The managed device decrypts the traffic using the session key obtained with the known server key, generates a connection event, and sends the connection event to the Management Center. The device inspects the decrypted traffic, does not match it against an access control rule, and stops inspecting it. It then reencrypts the traffic and passes it to the destination host.

The following steps occur:

  1. The user submits the plain text request (stats). The client encrypts this (AaBbC) and sends the encrypted traffic to the Underwriting department server.

  2. The external router receives the traffic and routes it to the Underwriting department server.

  3. The managed device uses the session key obtained with the uploaded known private key to decrypt this traffic to plain text (stats).

    The access control policy continues to process the decrypted traffic with the custom intrusion policy and does not find a spoof attempt. The device passes the encrypted traffic (AaBbC), then generates a connection event after the session ends.

  4. The internal router receives the traffic and routes it to the Underwriting department server.

  5. The Underwriting department server receives the encrypted information (AaBbC) and decrypts it to plain text (stats).

  6. The Firepower Management Center receives the connection event with information about the encrypted and decrypted traffic.

In contrast, any decrypted traffic that is a spoof attempt is dropped. The system logs the connection and the spoof attempt.


Diagram illustrating the Decrypt - Known Key action in an inline deployment inspecting a spoof attempt. The external host sends encrypted traffic to an internal host. The router routes traffic, and the inline managed device receives it. The managed device decrypts the traffic using the session key obtained with the known server key, generates a connection event, and sends the connection event to the Management Center. The device matches the decrypted traffic against an access control rule and blocks the traffic, generates a connection event, and sends it to the Management Center.

The following steps occur:

  1. The user submits the plain text request (spoof), altering the traffic to appear to originate from MedRepo, LLC. The client encrypts this (FfGgH) and sends the encrypted traffic to the Underwriting department server.

  2. The managed device uses the session key obtained with the uploaded known private key to decrypt this traffic to plain text (spoof).

    The access control policy continues to process the decrypted traffic with the custom intrusion policy and finds a spoof attempt. The device blocks the traffic, then generates an intrusion event. It generates a connection event after the session ends.

  3. The internal router does not receive the blocked traffic.

  4. The Underwriting department server does not receive the blocked traffic.

  5. The Firepower Management Center receives a connection event with information about the encrypted and decrypted traffic, and an intrusion event for the spoofing attempt.

Encrypted Traffic Inspection with a Re-signed Certificate in an Inline Deployment

For all TLS/SSL-encrypted traffic sent from the new and junior underwriters to MedRepo’s requests department, the system uses a re-signed server certificate to obtain session keys, then decrypts the traffic and logs the connection. Legitimate traffic is allowed and reencrypted before being sent to MedRepo.


Note

When decrypting traffic in an inline deployment by re-signing the server certificate, the device 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. As a result, each session contains different cryptographic session details.


Diagram illustrating the Decrypt - Resign action in an inline deployment. The internal host sends encrypted traffic to an external host. The router routes traffic, and the inline managed device receives it. The managed device resigns the server certificate during the SSL handshake. It decrypts the traffic using the resigned certificate, generates a connection event, and sends the connection event to the Firepower Management Center. It then reencrypts the traffic and passes it to the destination host.

The following steps occur:

  1. The user submits the plain text request (help). The client encrypts this (AaBb) and sends the encrypted traffic to the Requests department server.

  2. The internal router receives the traffic and routes it to the Requests department server.

  3. The managed device uses the session key obtained with a re-signed server certificate and private key to decrypt this traffic to plain text (help).

    The access control policy continues to process the decrypted traffic with the custom intrusion policy and does not find an improper request. The device reencrypts the traffic (CcDd), allowing it to pass. It generates a connection event after the session ends.

  4. The external router receives the traffic and routes it to the Requests department server.

  5. The Requests department server receives the encrypted information (CcDd) and decrypts it to plain text (help).

  6. The Firepower Management Center receives the connection event with information about the encrypted and decrypted traffic.


Note

Traffic encrypted with a re-signed server certificate causes client browsers to warn that the certificate is not trusted. To avoid this, add the CA certificate to the organization’s domain root trusted certificates store or the client trusted certificates store.

In contrast, any decrypted traffic that contains information that does not meet regulatory requirements is dropped. The system logs the connection and the non-conforming information.


Diagram illustrating the Decrypt - Resign action in an inline deployment. The internal host sends encrypted traffic to an external host. The router routes traffic, and the inline managed device receives it. The managed device resigns the server certificate during the SSL handshake. It decrypts the traffic using the resigned certificate, generates a connection event, and sends the connection event to the Management Center. The device matches the decrypted traffic against an access control rule, blocks it, and resets the connection. It generates a connection event and sends it to the Management Center.

The following steps occur:

  1. The user submits the plain text request (regs), which does not comply with regulatory requirements. The client encrypts this (EeFf) and sends the encrypted traffic to the Requests department server.

  2. The internal router receives the traffic and routes it to the Requests department server.

  3. The managed device uses the session key obtained with a re-signed server certificate and private key to decrypt this traffic to plain text (regs).

    The access control policy continues to process the decrypted traffic with the custom intrusion policy and finds an improper request. The device blocks the traffic, then generates an intrusion event. It generates a connection event after the session ends.

  4. The external router does not receive the blocked traffic.

  5. The Requests department server does not receive the blocked traffic.

  6. The Firepower Management Center receives a connection event with information about the encrypted and decrypted traffic, and an intrusion event for the improper request.

History for TLS/SSL

Feature

Version

Details

Extended Master Secret extension supported (see RFC 7627)

6.3.0.1

The TLS Extended Master Secret extension is supported for SSL policies; specifically, policies with a rule action of Decrypt - Resign or Decrypt - Known Key.

Extended Master Secret extension supported (see RFC 7627)

6.2.3.9

The TLS Extended Master Secret extension is supported for SSL policies; specifically, policies with a rule action of Decrypt - Resign or Decrypt - Known Key.

Category and reputation conditions supported

6.2.2

Access control rules or SSL rules with category/reputation conditions.

SafeSearch supported

6.1.0

  • The system displays an HTTP response page for connections decrypted by the SSL policy, then blocked (or interactively blocked) either by access control rules or by the access control policy default action. In these cases, the system encrypts the response page and sends it at the end of the reencrypted SSL stream.

  • SafeSearch filters objectionable content and stops people from searching adult sites.