SSL Decryption with Decrypt-Resign On Cisco FTD In-depth

Welcome, everyone. Today, we’re going to delve into an important aspect of network security using Cisco Firepower Threat Defense (FTD)—specifically, the SSL Decryption techniques and their practical implementations. We’ll focus primarily on the “Decrypt-Resign” method, which is crucial for handling outbound SSL connections.

Introduction to SSL Decryption Methods

In Cisco Firepower Threat Defense, there are two primary actions within the SSL Policy for decryption:

1. Decrypt-Resign: This is used for outbound connections, where traffic originates from an internal device and heads towards an external server.
2. Decrypt-Known-Key: This method is applicable for inbound connections, where traffic comes from an external device towards an internal server.

Challenges of Decrypt-Resign

The main challenge with Decrypt-Resign arises because we do not possess the private key of the external server—since it is not under our administrative control. The essence of SSL decryption in this context lies in how we handle certificates and keys.

Why is the Private Key Important?

The private key of a server is crucial because, without it, the FTD cannot present the real certificate of the external server. This key works alongside the server’s public key to exchange a symmetric key securely, which is subsequently used to encrypt and decrypt the data exchanged with the server.

Standard SSL Handshake Process

To better understand, let’s review how an SSL handshake typically occurs without an intervening device like the FTD:

• Step 1: The client (internal PC) sends an SSL “Client Hello” message, proposing encryption algorithms (like AES or 3DES) and requesting the server’s certificate.
• Step 2: The server responds with an “SSL Server Hello,” which includes the chosen cipher, its certificate, and its public key.

The client then verifies the server’s certificate signature using the public key of the Certificate Authority (CA) that issued the server’s certificate. Once the certificate is validated, and since a symmetric algorithm like AES is used, the client generates an encrypted key (EK), which it then securely sends to the server encrypted with its public key.

Introducing FTD into the Process

When inserting FTD in this exchange, it effectively performs a Man-In-The-Middle (MITM) attack. FTD positions itself between the client and the server, acting as the server to the client and as the client to the server.

FTD as a Certification Authority

One crucial configuration step is defining FTD as a Certification Authority (CA). This allows FTD to either generate its own private key or use a private key from an internal ROOT CA. This role enables FTD to spoof or replicate the original server’s certificate, inserting its public key in the spoofed certificate.

The Dual SSL Handshakes

With FTD in place, there are two SSL handshakes:

• From Client to FTD: The client believes it communicates directly with the original server but is interfacing with the FTD.
• From FTD to Server: FTD acts as the client to the external server.

Unlike the “Decrypt-Known-Key” method used for inbound connections, where the same certificate and public key are reused, the “Decrypt-Resign” method uses two different certificates: the original from the server and a spoofed version from the FTD. Both maintain attributes like Common Names and Subject Alternative Names.

Decryption and Data Flow

Finally, the FTD and the client generate the encryption keys (EK1 and EK2). These keys are used to decrypt and re-encrypt the data passing between the client and the server, ensuring that data confidentiality and integrity are maintained throughout the transaction. FTD effectively decrypts and inspects all transferred data.

Cisco Firepower Threat Defense there are two ways to do SSL Decryption (two actions in the SSL Policy).

Decrypt-Resign: for outbound connection (from an inside PC to an external server).

Decrypt-Known-Key: for inbound connection (from an external PC to your internal server).

Let’s focus on the Decrypt-Resign.

The challenge in this case is that we don’t have the external server’s private certificate since it’s not under your control.

Why do we need this private key? Without it, FTD cannot present the real certificate of the external SRV, and this private key is essentially used together with the public key.

to securely exchange the symmetric key that will be used later to encrypt and decrpt the data with the external server.

Basically, the SSL handshake without FTD is negotiated as follow:

Client PC ---SSL Client Hello (proposal cipher:AES,3DES + req certi)---> Server (note the cipher is the symmetric algo that will be used to encr/decr the data.

Client PC <---SSL Server Hello (chosen cipher AES, certi + public key of the SRV = K1)--- Server

Now, the PC first validates the certificate’s signature using the public key of the CA (K2) that signed the server’s certificate.

Once the validation process is done, since the AES is a symmetric algorithm, we need the secret key to securely exchange the data. Let’s call it the Encrypted Key (EK).

Therefore, The PC generates the Encrypt Key EK. Now, the PC must send this EK to the SRV securely. To do that, it takes the Encrypted Key EK and sends it encrypted with the server’s Public Key (K1).

Client PC ---(I send you the Encrypted Key encrypted with your public key)---> Server

The server decrypts the message with its private key and retrieves the Encrypted Key EK.

Now:

Client PC <---(Data are encrypted with AES using the encrypted key EK)---> Server

By inserting the FTD at the middle, it will do the MAN-IN-MIDDLE ATTACK, to do that, the FTD will act as the CA (this is why you create either the FTD with the role Certification of Authority ( so the private key is generated automatically inside the system) or you upload your internal ROOT CA with its private key.

Now, another question arises: why must we define the FTD as the CA? This role allows the FTD to create a copy of the original certificate (external SRV); in other words, it spoofs it and puts its public key in this spoofed certificate.

The result is two SSL Handshake, client-side and server-side, with FTD as the server on the client-side connection and as the client on the server-side connection.

Client PC <-----SSL handshake-----> (SRV) FTD (client) <-----SSL handshake----> Server

Unlike the decrypt-known key for inbound connections, where the same certificate with the same public key is used on both SSL handshakes. With the decrypt-resign, we have two certificates (original in the server side and a copy in the client side), of course with the same attributes such as the Common Name, SAN and so on, but very importantly,

The originale certificate has the public key of the external server and signed by an external CA.

The spoofed certificate created in the fly by FTD has the public key of FTD (or your internal CA) and signed by FTD (or by your internal CA).

Now the process of the SSL Handshake is the same as with the scenario without the FTD.

Client PC <-----SSL handshake-----> (SRV) FTD (client) <-----SSL handshake----> Server

The external server sends its certificate, the FTD as the client validates it using the public key of the external CA. The FTD will generate an encrypted key EK1.

The FTD sends the spoofed certificate, the Client PC validates it using the public key of the FTD (or your internal CA). The PC will generate an encrypted key EK2.

Client PC <-----(send EK1 encrypted with pub key of FTD or internal CA)-----> (SRV) FTD (client) <-----send EK2 encrypted with pub key of SRV----> Server

The FTD decrypt the message with its private key and retrieves the Encrypted Key EK1.

The server decrypt the message with its private key and retrieves the Encrypted Key EK2.

Now the SSL Decyption is in place.

Client PC <----DATA encr/decr with EK1----> (SRV) FTD (client) <-----DATA encr/decr with EK2----> Server