About SSL Decryption
Normally, connections go through the access control policy to determine if they are allowed or blocked. However, if you enable the SSL decryption policy, encrypted connections are first sent through the SSL decryption policy to determine if they should be decrypted or blocked. Any unblocked connections, whether or not decrypted, then go through the access control policy for a final allow/block decision.
Note |
You must enable the SSL decryption policy in order to implement active authentication rules in the identity policy. If you enable SSL decryption to enable identity policies, but do not otherwise want to implement SSL decryption, select Do Not Decrypt for the default action and do not create additional SSL decryption rules. The identity policy automatically generates whatever rules it needs. |
The following topics explain encrypted traffic flow management and decryption in more detail.
Why Implement SSL Decryption?
Encrypted traffic, such as HTTPS connections, cannot be inspected.
Many connections are legitimately encrypted, such as connections to banks and other financial institutions. Many web sites use encryption to protect privacy or sensitive data. For example, your connection to the FDM is encrypted.
However, users can also hide undesirable traffic within encrypted connections.
By implementing SSL decryption, you can decrypt connections, inspect them to ensure they do not contain threats or other undesirable traffic, and then re-encrypt them before allowing the connection to proceed. (The decrypted traffic goes through your access control policy and matches rules based on inspected characteristics of the decrypted connection, not on the encrypted characteristics.) This balances your need to apply access control policies with the user’s need to protect sensitive information.
You can also configure SSL decryption rules to block encrypted traffic of types you know you do not want on your network.
Keep in mind that decrypting and then re-encrypting traffic adds a processing load on the device, which will reduce overall system performance.
Actions You Can Apply to Encrypted Traffic
When configuring SSL decryption rules, you can apply the actions described in the following topics. These actions are also available for the default action, which applies to any traffic that does not match an explicit rule.
Note |
Any traffic that passes through the SSL decryption policy must then pass through the access control policy. Except for traffic you drop in the SSL decryption policy, the ultimate allow or drop decision rests with the access control policy. |
Decrypt Re-Sign
If you elect to decrypt and re-sign traffic, the system acts as a man-in-the-middle.
For example, the user types in https://www.cisco.com in a browser. The traffic reaches the Firepower Threat Defense device, the device then negotiates with the user using the CA certificate specified in the rule and builds an SSL tunnel between the user and the Firepower Threat Defense device. At the same time the device connects to https://www.cisco.com and creates an SSL tunnel between the server and the Firepower Threat Defense device.
Thus, the user sees the CA certificate configured for the SSL decryption rule instead of the certificate from www.cisco.com. The user must trust the certificate to complete the connection. The Firepower Threat Defense device then performs decryption/re-encryption in both directions for traffic between the user and destination server.
Note |
If the client does not trust the 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. |
If you configure a rule with the Decrypt Re-Sign 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 can select a single re-sign certificate for the SSL decryption policy, this can limit traffic matching for resign rules.
For example, outgoing traffic encrypted with an elliptic curve (EC) algorithm matches a Decrypt Re-Sign rule only if the re-sign certificate is an EC-based CA certificate. Similarly, traffic encrypted with an RSA algorithm matches Decrypt Re-Sign rules only if the global re-sign certificate is RSA; outgoing traffic encrypted with an EC algorithm does not match the rule, even if all other configured rule conditions match.
Decrypt Known Key
If you own the destination server, you can implement decryption with a known key. In this case, when the user opens a connection to https://www.cisco.com, the user sees the actual certificate for www.cisco.com, even though it is the Firepower Threat Defense device that is presenting the certificate.
Your organization must be the owner of the domain and certificate. For the example of cisco.com the only possible way to have the end user see Cisco’s certificate would be if you actually own the domain cisco.com (i.e. you are Cisco Systems) and have ownership of the cisco.com certificate signed by a public CA. You can only decrypt with known keys for sites that your organization owns.
The main purpose of decrypting with a known key is to decrypt traffic heading to your HTTPS server to protect your servers from external attacks. For inspecting client side traffic to external HTTPS sites, you must use decrypt re-sign as you do not own the servers.
Note |
To use known key decryption, you must upload the server’s certificate and key as an internal identity certificate, and then add it to the list of known-key certificates in the SSL decryption policy settings. Then, you can write the rule for known-key decryption with the server’s address as the destination address. For information on adding the certificate to the SSL decryption policy, see Configure Certificates for Known Key and Re-Sign Decryption. |
Do Not Decrypt
If you elect to bypass decryption for certain types of traffic, no processing is done on the traffic. The encrypted traffic proceeds to the access control policy, where it is allowed or dropped based on the access control rule it matches.
Block
You can simply block encrypted traffic that matches an SSL decryption rule. Blocking in the SSL decryption policy prevents the connection from reaching the access control policy.
When you block an HTTPS connection, the user does not see the system default block response page. Instead, the user sees the browser’s default page for a secure connection failure. 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 will not be obvious from this message that you blocked the connection on purpose.
Automatically Generated SSL Decryption Rules
Whether you enable the SSL decryption policy, the system automatically generates Decrypt Re-sign rules for each identity policy rule that implements active authentication. This is required to enable active authentication for HTTPS connections.
When you enable the SSL decryption policy, you see these rules under the Identity Policy Active Authentication Rules heading. These rules are grouped at the top of the SSL decryption policy. The rules are read only. You can change them only by altering your identity policy.
Handling Undecryptable Traffic
There are several characteristics that make a connection undecryptable. If a connection has any of the following characteristics, the default action is applied to the connection regardless of any rule the connection would otherwise match. If you select Block as your default action (rather than Do Not Decrypt), you might run into issues, including excessive drops of legitimate traffic.
-
Compressed session—Data compression was applied to the connection.
-
SSLv2 session—The minimum supported SSL version is SSLv3.
-
Unknown cipher suite—The system does not recognize the cipher suite for the connection.
-
Unsupported cipher suite—The system does not support decryption based on the detected cipher suite.
-
Session not cached—The SSL session has session reuse enabled, the client and server reestablished the session with the session identifier, and the system did not cache that session identifier.
-
Handshake errors—An error occurred during the SSL handshake negotiation.
-
Decryption errors—An error occurred during the decryption operation.
-
Passive interface traffic—All traffic on passive interfaces (passive security zones) is undecryptable.