On 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 dont have the private certificate of the external server since it's not under your control.
The question why do we need this private key? because without this private key 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 negociated 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 signature of the certificate 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 algo, we need the secret key to securely exhange the data. let's call it the Encrypted Key EK.
Therefore The PC generate 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 Public Key of the server (K1).
Client PC ---(I send you the Encrypted Key encrypted with your public key)---> Server
The server decrypt 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 do we need to define the FTD as the CA? this role provides the FTD the ability to create a copy of the originale certificate (external srv), in other words it spoofs it and puts its public key in the 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 with the decrypt-known-key for inbound connection where the same certificate with the same public key is used on both SSL handshake. With the decrypt-resign we have two certificates (originale 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 important,
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
