SSL Policy
Cisco Secure Firewall SSL Policy Guidance
Introduction
The rapid rise in encrypted traffic is transforming the threat landscape. As of August 2020, 95% of Google's traffic is encrypted, and nearly 85% of the webpages loaded by Firefox are encrypted. Based on an earlier Gartner estimate from 2019, more than 80% of enterprise web traffic was encrypted, and a recent Gartner report states that 54% of network threats are found in encrypted traffic.
Visibility into encrypted traffic is critical for effective network security. However, TLS decryption is a resource-intensive process and, if improperly configured, could potentially allow attacks and even degrade the end-user experience. This document covers the best practices for configuring TLS inspection on Secure Firewall.
Note
Before we go any further, you may have already noticed that TLS and SSL are often used interchangeably. We use TLS/SSL to indicate that either protocol is being discussed. The IETF has deprecated the SSL protocol 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 Firepower Management Center configuration option is Policies > Access Control > SSL, we use the term SSL policies although these policies define rules for TLS and SSL traffic.
For more information about SSL and TLS protocols, visit a resource such as SSL vs. TLS - What's the Difference?
SSL Decryption Policy
The SSL policy governs how Firepower Threat Defense (FTD) handles encrypted traffic. Visibility into the TLS encrypted traffic provides better information for IPS inspection, File and Malware detection, and micro application visibility. Apart from inspecting flows, you can use the TLS/SSL policies to block server connections supporting older SSL/TLS versions or weak ciphers.
If configured, SSL policy evaluation occurs before an IPS and File Policy, as illustrated here:
Figure 1: Encrypted Traffic Processing
Evaluation of SSL Rules
The SSL rules are evaluated top-down. Based on the field used to define the SSL rule, some flows might match more than one rule, called an "ambiguous match." Figure 2 below shows the various fields available to configure an SSL rule match. The SSL rule's complexity determines the resources used to establish the policy match's verdict for a flow.
Figure 2: SSL Rule Fields
Three broad information categories to match a TLS policy rule determine the effort involved:
| Before TLS Handshake | TLS Client Hello | TLS Server Response |
|---|---|---|
| FTD has the L2-L4 information about the flow | FTD has the additional information of SNI ( Server Name Identification | Server Certificate information and Server Hello |
| Interface Zones, Networks, Geolocation, VLAN Tags, User Identity, Protocol and Ports | Application, URL Category and Reputation | Certificate attributes, Ciphers, Versions, SNI mismatch |
| TLS handshake inspection not required | Initial match using SNI | Most reliable information |
SSL Policy Rule Actions
Figure 3: SSL Rule Actions
TLS Decryption Deployment Modes
| Inbound | Outbound |
|---|---|
| Use Server Private Key and certificate | Resign External Server Certificate using Internal CA |
| Protects internal servers | Inspect Outbound traffic |
| Decrypt -- Known Key | Decrypt -Resign |
Figure 4: Outbound - Decrypt with Resign
Figure 5: Inbound - Decrypt with Known Key
Decrypt Resign rules require Internal CA objects, for which there are three options:
- A Self-Signed Certificate using the FMC as the Root CA
- Use the Internal Organization CA to sign the FMC certificate
- Import an Internal CA certificate
Figure 6: PKI Options
Figure 7: Internal Certificate Authorities
Figure 8: Internal Certificates
Best Practice
A self-signed certificate using the FMC is not recommended as the users' browsers do not trust the FMC certificate, causing all the decrypted sessions to generate browser certificate errors.
Decrypt Known Key rules require Internal Certs Objects. The Decrypt with Known Key rule is selected when the traffic matches the rule, and the certificate used to encrypt the traffic matches the certificate associated with the rule.
Configuration
You can configure multiple SSL policies. However, only one SSL policy is associated with an access control policy, which can be associated with one or more Secure Firewall devices. As explained earlier, SSL rules require various degrees of information to match a flow and reach a verdict. The recommended SSL policy configuration is comprised of three sections:
Global Settings ( Trusted CA Certificates and Undecryptable Actions )
Trusted CA Certificates
The SSL policy includes a wide range of trusted CA root and intermediate certificates issued by third parties. When creating an SSL policy, a trusted CA group object called "Cisco-Trusted-Authorities" is added by default. These are needed when configuring "Decrypt-Resign" rules using the certificate status of the external server.
To add a Trusted CA, we recommended uploading all certificates within a root CA's chain of trust to the Trusted CA certificates. A requirement to detect certificates issued by intermediate CAs.
Figure 9: Trusted CA Certificates
Undecryptable Actions
These settings configure FTD to handle an undecryptable flow.
Figure 10: Undecryptable Actions
The above screenshot shows the recommended default settings for the undecryptable traffic with the default action as "Do Not Decrypt."
Default Action ( Default SSL Policy Action and Logging )
When creating a new SSL policy, the default action for traffic that does not match any SSL rules is Do Not Decrypt. For most cases, this is the recommended setting. However, to block all TLS connections that do not match a decryption rule, set the Default Action to Block/Block with Reset.
Figure 11: SSL Rule Logging Options
When allowing undecryptable connections, it is essential to track connections through Default Logging settings (using **Do Not Decrypt** as the Default Action).
SSL Rule Recommendations
Rule Ordering
The recommended order of configuring SSL rules is to arrange the rules such that the rules that require the least amount of information to determine the outcome are at the top. Also, bear in mind the need to only decrypt necessary traffic. Therefore place the Block and Do Not Decrypt rules before the Decrypt Known Key and Decrypt Resign rules.
Figure 12: SSL Rules
Protection from 'weak' TLS Servers
Block Traffic to sites using weak TLS ciphers, older TLS versions or problematic certificates (e.g. invalid, self-signed).
Figure 13: Blocking based on Certificate Status
Figure 14: Blocking based on Weak Ciphers
Figure 15: Blocking based on SSL/TLS Version
Special Considerations
Replace Known Key for Decrypt with Resign
For the Decrypt -- Resign action, Firepower replaces the public key. The Replace Key checkbox determines how to apply the decrypt action to self-signed server certificates.
If deselecting the Replace Key checkbox, self-signed certificates are treated like any other server certificate. Secure Firewall replaces the key and resigns the certificate. Generally, the endpoint is configured to trust Secure Firewall and therefore trusts the resigned certificate.
If Replace Key is selected, self-signed certificates are handled differently. Firepower replaces the key and generates a new self-signed certificate causing the endpoint's browser to generate a certificate warning.
EUN (End User Notification) for Blocked Traffic
Figure 16: End User Response Configuration
The HTTP Block Response page is configured as part of the Access Control Policy settings and displayed for HTTP and HTTPS(TLS) connections blocked by FTD. However, for TLS connections, the Block Response Page is displayed only if the TLS connection is decrypted by the SSL policy before an access control policy rule blocks it.
The Block Response Page is not displayed for TLS traffic not decrypted by FTD, irrespective of the reason for the traffic block.
TLS Client Hello Modification
If the TLS Client Hello message matches a Decrypt - Resign rule, FTD will modify it. This function is enabled by default. Along with other information present in the TLS Client Hello packet, FTD uses the SNI field to predict the need for modification. However, since the TLS SNI can be spoofed, the final decision is based on the Server response.
Figure 17: TLS SNI Matching
As shown above, we can block any TLS connection where the SNI field does not match the Server Response. However, this could affect the performance negatively because :
-
FTD might have to modify the TLS Client Hello more often
-
If the TLS Client Hello has already been modified, but the TLS flow was not supposed to be decrypted, FTD cannot disengage and direct the TLS connection to Do Not Decrypt. Due to the Client Hello modification, the Message Authentication Codes (MAC) computed by the client and the server no longer match, so FTD still has to proxy the complete TLS/SSL handshake between the client and server.
Note
More information about how the changes to the TLS Client Hello are done is available here.
Handling TLS 1.3 Servers
TLS1.3 encrypts the Server Certification information and might allow for the SNI information encryption in the Client Hello. FTD does not have visibility into the Server Certificate during a TLS1.3 exchange and currently does not support TLS1.3 inspection. It inspects by modifying the client TLS Client Hello during the initial evaluation and forcing the server to negotiate on TLS1.2, called Aggressive Downgrade.
Most browsers now enforce TLS1.3 unless required to inspect all the TLS1.3 connections. The recommendation is to keep Aggressive Downgrade disabled as it could lead to FTD processing additional TLS flows and browser errors in some cases.
Browser Errors related to Untrusted Certificates
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.
Exceptions from Decryption
You might exempt traffic from decryption for various reasons: performance gain or end-user experience. Many mobile devices and enterprise SaaS cloud applications use mutual authentication or certificate pinning to validate the application server's certificate. Since FTD modifies the server certificate during outbound decryption ( decrypt -- resign ), the client application does not accept the server certificate causing the TLS connection to fail.
Suggested exemptions from Decryption:
- Trusted Vendor domains and Trusted Subnets ( Low risk )
- Guest Networks
- Internal Server Backups or Trusted Flows
- Enterprise SaaS Application Traffic such as Office 365, Microsoft updates, Apple updates etc.
- TLS traffic using TLS Heartbeat
Verification/Troubleshooting
The Connection Events Viewer provides insight into flow evaluation against an SSL policy rule. Not only does the event viewer help identify if the correct rule is being matched, it also reports any SSL errors as part of the TLS handshake. If you do not see SSL information for the flow of interest, ensure that logging is enabled in the SSL rules and corresponding Access Control Policy rules.
Use the output of the following commands to check for TLS oversubscription and various TLS processing statistics:
show snort tls-offload
show counters
Gather advanced information by using a combination of debugs such as:
system support debug
system support ssl-debug
Warning
The SSL debugs should only be enabled and collected under supervision by TAC. As SSL debugs are verbose, the right level of debugging information needs to be configured depending on the issues.
Summary
SSL policies play an essential role in protecting against threats. An optimally configured SSL policy protects your environment against attack vectors embedded in encrypted traffic and ensures a problem-free end-user experience. SSL policies slowly evolve as the needs of the organization change. Firepower Release 6.4 and higher use dedicated hardware-based decryption, by default, on Firepower appliances (Firepower platform series 1000, 2100, 4100, and 9300) and cannot be disabled without TAC's assistance. Using hardware acceleration for TLS operations ensures high performance without compromising security.
📚 Additional Resources
Updated almost 3 years ago