Cisco Firepower SSL Decryption: Decrypt Re-Sign

SSL Decryption on firewalls is a process where the firewall temporarily decrypts SSL/TLS encrypted traffic. This allows the firewall to inspect the contents for threats like malware, data exfiltration, or policy violations that would otherwise be hidden in encrypted traffic. Once checked, the traffic is re-encrypted and sent to its destination. This capability helps maintain higher security standards by enabling better visibility into network traffic, but it must be managed carefully to balance security with privacy and compliance requirements.

What is the Cisco FTD Decryption Policy?

The latest Cisco Firepower Threat Defense (FTD) includes an SSL decryption policy that supports TLS 1.3 decryption when managed by Cisco FMC or Cisco Defense Orchestrator software. In the Firepower Management Center (FMC), you can enable TLS 1.3 decryption within the SSL policy settings. This involves logging into the FMC web interface, navigating to the Policies menu, selecting SSL, and then editing the specific SSL Policy to enable or disable TLS 1.3 decryption via the Advanced Settings tab.

Cisco has introduced various security and configuration settings in their latest versions to ensure robust management and compliance with modern security standards. It’s important to keep your system up-to-date and configure SSL policies according to your organization’s security requirements. For more detailed steps and guidance, it’s recommended to refer to Cisco’s official documentation or directly access the configuration settings through the Cisco FMC or Defense Orchestrator interfaces.

Application 1 : Decrypt Re-Sign

The “Decrypt-Resign” action in Cisco Firepower Threat Defense (FTD) is a method used for SSL decryption, specifically for outbound connections from an internal network to external servers. This action involves the Firepower device acting as a man-in-the-middle by decrypting and then re-encrypting traffic.

Here’s how it works:

1. Decrypting Traffic: When traffic matches a rule specifying “Decrypt-Resign,” FTD decrypts the SSL/TLS traffic using a copy of the server’s certificate, which the FTD or an internal CA has re-signed.
2. Certificate Management: FTD modifies and re-signs the original server certificate, effectively spoofing the certificate to insert itself into the communication path.
3. Re-encryption: After inspecting and possibly modifying the decrypted traffic, FTD re-encrypts the data before sending it to the original destination server. The client sees a certificate signed by the internal CA instead of the external server’s CA.

The primary purpose of this process is to allow the FTD to inspect encrypted traffic for security threats like malware or data exfiltration attempts. However, it requires careful management of trust and certificates within the network to ensure security and user trust, particularly around the handling of certificate warnings and the potential implications for privacy and compliance.

For managing these settings, the FTD integrates with the Firepower Management Center (FMC), where you can configure and manage SSL policies, including the specifics of “Decrypt-Resign” actions.

https://www.cisco.com/c/en/us/td/docs/security/firepower/710/fdm/fptd-fdm-config-guide-710.html

Scenario: Protecting Against Data Exfiltration in a Financial Services Firm

Background: A financial services firm, “SecureFinance Corp,” has been concerned about the security of its outbound internet traffic, particularly the potential for sensitive financial data to be exfiltrated via encrypted channels that evade standard detection mechanisms.

Objective: Implement SSL decryption to inspect encrypted traffic for signs of malware, data exfiltration, or other malicious activities, without disrupting legitimate business operations.

Implementation:

1. Preparation and Planning:
   • SecureFinance Corp’s IT team reviews their existing network architecture and traffic flow to determine the best points to deploy Cisco FTD for SSL decryption.
   • They identify the main exit points where internal users access external financial portals and cloud services.
2. Deployment of Cisco FTD:
   • FTD devices are deployed at strategic points where they can effectively intercept outbound SSL/TLS traffic.
   • The IT team ensures that all traffic destined for the internet passes through these devices.
3. Configuration of Decrypt-Resign:
   • Using the Firepower Management Center (FMC), the IT team configures SSL decryption policies.
   • They select the “Decrypt-Resign” action for outbound traffic. This involves re-signing the SSL certificates with SecureFinance Corp’s internal Certificate Authority (CA), which is trusted by all internal clients.
   • Special attention is given to financial domains and cloud storage services, where sensitive data might be transmitted.
4. Testing and Validation:
   • Initial testing is conducted in a controlled environment to ensure that decryption and re-signing processes do not break legitimate applications or services.
   • The IT team carefully monitors the first few days of deployment to handle any issues with certificate errors or service disruptions.
5. Ongoing Monitoring and Incident Response:
   • Once fully operational, the decrypted traffic is continuously monitored for unusual activities or data patterns that could indicate a security breach.
   • If malicious traffic or data exfiltration attempts are detected, alerts are generated for immediate action by the security team.
6. Compliance and Privacy Considerations:
   • The firm ensures that all monitoring activities are compliant with regulatory requirements regarding data privacy and protection.
   • Employees are informed about the monitoring to maintain transparency and trust.

Outcome: The deployment of Cisco FTD with Decrypt-Resign allows SecureFinance Corp to enhance its security posture by providing visibility into encrypted traffic, thereby significantly reducing the risk of data breaches through encrypted exfiltration paths. Regular audits and reviews help maintain the effectiveness of the solution and compliance with industry standards.

This scenario demonstrates the critical role of SSL decryption in protecting sensitive information in industries where data security is paramount, utilizing tools like Cisco FTD to balance security with operational integrity.

Application 2 : Decrypt Known Key

The “Decrypt Known Key” method in Cisco Firepower Threat Defense (FTD) is used for inspecting inbound SSL/TLS traffic to internal servers. Here’s a concise overview:

1. Configuration: The private key of an internal server is uploaded to the FTD, enabling it to decrypt incoming encrypted traffic intended for this server.
2. Decryption and Inspection: FTD decrypts the SSL/TLS sessions using the server’s private key, inspects the traffic for security threats like malware or unauthorized data access, and then re-encrypts the data before sending it to the internal server.
3. Security and Integrity: This process allows detailed inspection while maintaining the confidentiality and integrity of the data between the external client and the internal server.

This approach is vital for ensuring the security of sensitive data being transmitted to internal services from external sources.

1. Using Decrypt Known Key: Cisco Firepower Threat Defense (FTD) needs to have both the server certificate and its private key to decrypt traffic. This is why the method is called “Decrypt Known Key.” It allows the FTD to decrypt data from users outside the network as it heads to the server, ensuring that it can be checked for threats or sensitive information.
2. SSL Offloading: After inspecting the traffic, Cisco FTD can send it to the server either as encrypted data or as plain text. Sending it as plain text is often done to lessen the load on the server from having to decrypt SSL traffic itself, a process known as “SSL offloading.” This helps improve server performance by reducing the amount of decryption work the server has to do.

Here’s a scenario that illustrates the use of “Decrypt Known Key” and “SSL Offloading” in a business context:

Scenario: Enhancing Security and Performance for an E-commerce Company

Background: A large e-commerce company, “ShopFast Inc.,” handles thousands of secure transactions daily. The IT team at ShopFast Inc. is concerned about the security of data being transmitted and the performance of their web servers during peak shopping hours.

Objective: Implement Cisco FTD’s “Decrypt Known Key” for enhanced security inspection and utilize “SSL Offloading” to improve server performance.

Implementation:

1. Setting Up Decrypt Known Key:
   • ShopFast Inc. uploads their web servers’ SSL certificates and private keys to their Cisco FTD device. This setup allows FTD to decrypt incoming traffic from users, inspect it for security threats such as credit card fraud or data breaches, and then re-encrypt it before passing it to the web servers.
2. Configuring SSL Offloading:
   • To reduce the load on their servers, ShopFast Inc. decides to implement SSL offloading. With this setup, the Cisco FTD decrypts incoming SSL traffic, inspects it, and then sends it to the servers in clear text. This means the servers do not have to use their resources to decrypt the traffic, allowing them to process requests faster and handle more transactions during busy times.
3. Monitoring and Adjustments:
   • The IT team closely monitors the new setup to ensure that it does not interfere with the user experience and that all transactions are securely handled. They make adjustments to the configurations as needed based on performance data and security alerts.
4. Outcome:
   • As a result, ShopFast Inc. experiences a significant improvement in server performance during high traffic periods, without compromising on security. The IT team is able to detect and respond to security threats more effectively, ensuring the safety of customer data.

This scenario demonstrates the dual benefits of using Cisco FTD’s “Decrypt Known Key” for security and “SSL Offloading” for performance, providing a practical solution for businesses handling sensitive data and high volumes of traffic.

Cisco FTD Decryption: Decrypt Re-Sign Configuration Procedure

To implementing the first type of Cisco FTD Decryption Policy:

1. Generate Internal CA Certificate: Create an internal CA certificate in Cisco FTD. This certificate will replace the real server’s certificate for clients within your network, ensuring all internal users trust it.
2. Configure SSL Decryption Policy: Set up an SSL policy in FTD to decrypt and re-sign the SSL traffic. This can be applied universally or targeted to specific sites based on your organizational needs.
3. Activate SSL Policy via Access Control: Integrate and enable the SSL decryption policy within the broader access control policy to start the decryption and inspection of SSL traffic.
4. Test and Monitor: After deployment, test the setup by accessing HTTPS websites and monitor Cisco FTD logs and connection events to ensure everything functions correctly and to troubleshoot any issues that arise.

Generate Cisco FTD Certificate as Internal CA

To generate a Cisco FTD certificate as an Internal CA, follow these general steps:

1. Log into Cisco FMC: Access your Cisco Firepower Management Center.
2. Navigate to Object Management: Go to Objects > PKI.
3. Create Internal CA: Select “Internal CAs” and then “Add Internal CA”.
4. Certificate Details: Fill in the required details such as the certificate name, common name, key length, and validity period.
5. Generate the Certificate: Submit the form to create and issue the Internal CA certificate.

This certificate will then be used by the Cisco FTD for Decrypt-Re-Sign SSL Decryption policies, allowing it to act as a trusted issuer for decrypted traffic.

Then the Certificate Request (CSR) must be sent to the CA in order to receive a certificate.

If you do not know how to install CA in Microsoft Server, I have already explained in a video named “3. SD-WAN Certificate Authority Configuration” in SD-WAN course.

CSR should be requested as a “Subordinate Certificate Authority” since Cisco FTD itself acts as a subordinate CA.

http://192.168.1.240/certsrv/ -> Request a Certificate ->  advanced certificate request ->

The downloaded certificate must be installed in Cisco FTD.

Notice that enterprise certificate CA must be trusted by FTD since it has signed already FTD certificate.

To do this, we download the CA certificate from Microsoft CA and add it to the “Trusted Certificate Authority” in Cisco FTD.

http://192.168.1.240/certsrv/ -> Download a CA certificate, certificate chain, or CRL -> Download CA certificate

Now the Cisco FTD certificate is ready and can be used by users inside the network, but don’t forget to trust it to the computers inside the network.

Configure SSL Policy to Decrypt and Re-Sign

In the next step, we have to add a SSL Policy. in our example we will decrypt all https websites except cisco.com.

To add a new SSL policy, first do not forget to trust enterprise CA certificate in your SSL Policy.

Policies -> SSL -> New Policy -> Trusted CA Certificates

Then we add two rules.

The first rule is to decrypt all SSL traffic with “Decrypt – Resign” Action. We choose FTD certificate which  has to be transferred to users instead of real servers certificate.  we do not forget to enable logging so we can monitor SSL traffic and corresponding  policy.

In the second rule, we choose “Do not decrypt” action for cisco application. So we expect that cisco.com traffic will not be decrypted. To monitor cisco.com traffic, we enable logging also in this rule.

Enable SSL Policy in Access Control Policy

SSL Policy will not work until it is activated in Access Control Policy.

Test, Monitor and Troubleshoot the “Decrypt Re-Sign” SSL Decryption Policy

Now we can check HTTPS websites from computers inside the network to evaluate our SSL Policy.

I add three fields in conenction events regarding SSL to better monitor SSL connections.

I browse three website, google.com, amazon.com and cisco.com to check the certificate and also connection event.

We expect that user can browse amazon.com and google.com with FTD certificate but cisco.com certificate will be the real certificate from user perspective.

Series Navigation

Cisco Firepower SSL Decryption: Decrypt Known Key >>