On Palo Alto Firewall there are two ways to do SSL Decryption (two actions in the Decryption Policy).
SSL Forward Proxy: for outbound connection (from an inside PC to an external server).
SSL Inbound Inspection: for inbound connection (from an external PC to your internal server).
For both option, we need to import the right certificates.
How and where?
On Palo Alto GUI:
Navigate to Device –> Certificate.
For inbound SSL decryption, you have to import the server's certificate and private key.
Then you create a Decryption Policy that matches the traffic coming from internet to your internal server with the action "SSL Inbound Inspection", and finally associate the server's certificate you uploaded previously.
For SSL Outbound SSL Decryption, we will go into details since there are some points that we need to take into considerations.
But before going into the certificate creation and the explanation of each options in the certificate configuration, let's deep dive how the Palo Alto Firewall acts as the Man in the Middle to decrypt outbound SSL Connection coming from your internal network to external servers on the Internet.
The challenge in this case is that we dont have the private key of the external server since it’s not under our control.
The question that arises why do we need this private key? because without this private key, Palo Alto Firewall cannot present the real certificate of the external Server 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 decrypt the data with the external server.
Basically the SSL handshake without Palo Alto Firewall is negociated as follow:
Client PC —–> SSL Client Hello (proposal cipher :AES,3DES + request certificate) —–> Server
Server —–> SSL Server Hello (chosen cipher AES, certificate + public key of the SRV = K1) —–> Client PC
By inserting the Palo Alto Firewall in the middle, it will do the MAN-IN-MIDDLE ATTACK, to do that, the Palo Alto Firewall will act as the CA.
Now another question that arises, why do we need to define the Palo Alto as the CA? this role provides the Palo Alto Firewall the ability to create a copy of the originale certificate (external Server) and the authority to sign it.
The result is: two SSL Handshake, from PC client to Palo Alto Firewall as the server, and from Palo Alto Firewall as the client to the external Server.
Client PC <—– SSL handshake —–> (Server) PaloAlto (client) <—– SSL handshake —–> Server
With SSL Forward Proxy, we have two certificates (the original certificate presented by the external server to Palo Alto Firewall and a copy of this certificate presented by Palo Alto Firewall to internal users),
The originale certificate has the public key of the external server and signed by an external CA.
For the spoofed certificate created by Palo Alto Firewall, it can be signed by either the Palo Alto Firewall itself acting as the CA or your enterprise CA.
Now two SSL handshakes are negociated as follow:
Client PC <—– SSL handshake —–> (Server) Palo Alto (client) <—– SSL handshake —–> External Server
The external server sends its certificate, the Palo Alto Firewall as the client validates it using the public key of the external CA. The Palo Alto Firewall negociates an encrypted key EK1 with the external server.
The Palo Alto Firewall creates and sends the spoofed certificate, the Client PC validates it using the public key of the Palo Alto Firewall (or your Enterprise CA). The PC negociates an encrypted key EK2 with Palo Alto Firewall.
Now the SSL Decyption is in place.
Client PC <—– DATA encrypted/decrypted with EK1 —–> (Server) FTD (client) <—– DATA encrypted/decrypted with EK2 —–> Server
Now you understood the process of SSL Decryption for outbound traffic with SSL Forward Proxy.
Let's move to configuration where many options are availables.
First as mentioned previously, for the spoofed certificate created by Palo Alto Firewall, it can be signed by either the Palo Alto Firewall acting as the CA or your enterprise CA using different methods.
The first method is to generate a Self Signed Root CA certificate on Palo Alto with the Role of Certificate Authority instead of using an enterprise CA's certificate. Define the Common Name and optionally Subject Alternative Name. The most important part in this configuration is to check the option (Certificate Authority), without this option, Palo Alto Firewall will generate a CSR Certificate Signing Request. This option instructs the Palo Alto Firewall to generate a certificate with the Role of Certificate Authority so that it can be used to sign other certificates as shown below.
Once the certificate is generated, you need to edit it and check the option "Forward Trust Certificate", this option instructs the Palo Alto Firewall to sign the spoofed certificate of the external server.
Let's test the connection to an internet website.
The second method is to create a CSR, then you generate a digital certificate with the role of Certificate Authority but signed by another Certificate Authority. In this case the Palo Alto Firewall will use an intermediate certificate to sign the spoofed server certificate, in other words the Palo Alto is the Subordinate CA of the Authority CA Server that signed its certificate.
The Certificate Auhtority that you will use to sign the CSR's Palo Alto Firewall is for example your Enterprise CA.
In this scenario you have two options to generate and submit the CSR, If you want to submit the CSR into the Enterprise CA, you need to select the option "Signe by : An External Authority (CSR)" as shown below.
Then you download the CSR. To generate the certificate, access the Enterprise CA and past the CSR, in this case you must select the Certificate Template "Subordinate Certificate Authority", then you generate the certificate with the role of Certificate Authority.
The second option which is more simple, the idea is to retrieve the Enterprise CA's certificate + the corresponding Private Key, then you upload both into the Palo Alto Firewall as shown below.
Once the Enterprise CA's certificate and the private key are uploaded, instead of using the Option "Signe by : An External Authority (CSR)", you scroll down and you select the Enterprise CA's certificate you uploaded previously as shown below, and you must also check the option "Certificate Authority", therefore you instruct the Palo Alto Firewall to generate by itself a Subordinate Certificate signed by the Enterprise CA's certificate and the private key.
Once the Subordinate Certificate is ready, you check the "Forward Trust Certificate" option.
Let's test a connection to an internet website.
The third method is to use the Enterprise CA's certificate to sign the spoofed certificate of the external server. To do this, you edit the Enterprise CA certificate you uploaded previously, then you check the "Forward Trust Certificate" option.
Let’s a connection to an internet website.
In some scenarios, the destination or the external server sends its own certificate signed by an untrusted CA, with the "Forward Trust Certificate" option, the original certificate issuer is hidden causing the user to receive a Trusted Certificate signed by Palo Alo Firewall's CA certificate which is already trusted by internal PCs. To warm the user and display a warning about the untrusted certificate so that it is up to the user to trust it or not, you need another certificate with the role of Certificate Authority, but when you generate the certificate that will be used for untrusted external server, do not sign this certificate with a Trusted Root CA the user's web browser trust or don’t use the Enterprise CA you used for Forward Trust Certificate.
Instead it is best practice to use a self-signed CA certificate with a significative Common Name as shown below.
Once the certificate is generated, you need to check the "Forward Untrust Certificate" option as shown below, this option will instruct the Palo Alto Firewall to sign any untrusted certificate received from an external server with this certificate so that users are prompted with a warning when trying to access web sites with untrusted certificates.
Let's test a connection to an untrusted server.
The last and interesting scenario is the case when some legitimate websites are sending their certificate and the Palo Alto does not trust the Certificate Authority that signs the external server's certificate, or the server is using certificate chain and the intermediate certificate is missing from the certificate path the server presented to the Palo Alto Firewall, it cannot trust the legitimate server and the certificate, the Palo Alto Firewall will presents its Forward Untrust Certificate to the client and blocks the connection because the option "Block Sessions With Untrusted CA" is enabled on the Decryption Profile and it's not a good idea to disable it as shown below.
In order to allow the users to access these legitimate websites with untrusted CA, the idea is to upload the Root or the Subordinate certificate that signed the website's certificate into the Palo Alto Firewall.
Once you upload it, you must check the option "Trusted Root CA".
Let’s test the connection to an untrusted server. Now the server’s certificate is spoofed and signed with the trusted certificate of the Palo Alto Firewall so the Forward Trust Certificate is applied as expected.
