Some protocols like HTTPS use Secure socket layer (SSL), transport layer protocol (TLS) to encrypt traffic for secure transmissions. As the system cant inspect encrypted connections we first must decrypt to apply access roles which consider higher layer traffic characteristics to determine access decisions. 

In today’s blog we will cover in detail about how Cisco FTD SSL decryption, how it works, its features and limitations.

Cisco FTD SSL Decryption

Connections go through access control policy to determine if they are allowed to pass or blocked. When SSL decryption policy is enabled, encrypted connections are first sent to SSL decryption policy to determine if they are allowed to remain encrypted and blocked or allowed to be decrypted. Any unblocked connections, go through access control policy for a final block or allow decision. 

Why is SSL Decryption Enabled?

Encrypted traffic like HTTPS connections is not possible to be inspected. Many connections which carry customer sensitive data such as banks and financial institutions connections to the FDM are encrypted. Also, users can hide undesirable traffic in encrypted connections. With the SSL decryption feature we can decrypt connections, inspect them to ensure they do not contain any threats or undesirable traffic and re-encrypt them before allowing them to proceed on to the network. The end objective is twofold here one is to apply access control policies and second , users need to protect sensitive information. 

SSL decryption rules can be configured to block encrypted traffic which you want to restrict. 

Actions associated with FTD SSL Decryption

Decrypt Re-sign  

If you decide to decrypt and re-sign traffic then the system acts as Man in the middle. When traffic reaches the FTD device, the device negotiates with the user and builds an SSL tunnel between user and FTD device. The device connects to the website and creates an SSL tunnel between server and FTD device. The user sees a CA certificate configured for the SSL decryption rule instead of a certificate from the website. The user must trust the certificate so as to complete the connection. The FTD device thus performs decryption/encryption in both directions for traffic between user and destination server.

Decrypt known key 

If you know the destination server, we can implement decryption with a known key. When the user opens a connection to the website, the user will see the actual certificate for the website which is presented by FTD device. Organization must be the owner of the domain and certificate. The main objective of decrypting with a known key is to decrypt traffic heading to your HTTPS server to protect it from external attacks.

Do not decrypt 

If you decide to bypass decryption for certain types of traffic , no processing will be done on traffic. The encrypted traffic proceeds to an access control policy where it is allowed or not allowed based on matching access control rules. 

Block 

We can simply block encrypted traffic which matches SSL decryption rules. Block at SSL decryption policy to prevent the connection from reaching access control policy.

Auto generation of FTD SSL decryption rules 

When you enable SSL decryption policy, the system automatically generates a Decrypt re-sign rule for each identity policy rule which implements active authentication. This is required to enable active authentication for HTTPS connections. 

Limitations of  FTD SSL Decryption

• Minimum supported SSL version is SSLV3
• The system does not recognize cipher suite for connection
• The system does not support decryption based on detected cypher suite
• System did not cache session identifier
• Errors occurring during SSL handshake negotiation

Continue Reading:

Palo Alto SSL Decryption

Fundamentals of FortiGate Firewall: Essential Guide

Are you preparing for your next interview?

Please check our e-store for e-book on Cisco FTD Interview Q&A. All the e-books are in easy to understand PDF Format, explained with relevant Diagrams (where required) for better ease of understanding.