More and more traffic is being encrypted. For this reason, for the firewall to inspect all traffic, it must also decrypt it due to high visibility, control, and protection at the highest levels.

SSL uses symmetric and asymmetric encryption.

  1. The client requires an SSL connection
  2. The server responds to the request by sending its certificate containing its identity and public key
  3. The client checks the certificate by looking for it in the list of known certificates. (PKI)
  4. The client generates a random symmetric key and encrypts it using the server’s public key.
  5. The server uses its private key to decrypt the session key (from step 4).

Types of decryption on Palo Alto Firewall

Palo Alto allows 3 types of decryption:

o SSL Forward Proxy

o SSL Inbound Inspection

o SSL Decryption

SSL Forward Proxy

SSL Forward Proxy decrypts SSL traffic between a host on your network and a server on the Internet. In this scenario, Palo Alto acts as an SSL Proxy that establishes a connection between your host and Palo Alto and separates (but logically related) communication between Palo Alto and the server on the Internet.

An example in which this type of encryption is helpful is when you allow employees in your network to read the Twitter line in your policies in Palo Alto. Still, you want to prohibit them from sending messages and posting content (tweeting). If SSL decryption is enabled, Palo Alto will easily distinguish within the policy whether Twitter traffic belongs to “reading,” “commenting,” or “chatting” and, based on that, defend or allow traffic. If encryption is not enabled, Palo Alto cannot know what type of application is within the SSL connection.

SSL Inbound Inspection

SSL Inbound Inspection decrypts traffic coming from external users to your internal services. For this decryption, you must have a server private key and certificate. In this scenario, Palo Alto does not act as a proxy but directly forwards the request to the internal server. For that reason, you need the previously mentioned certificates because the connection is formed directly between the host and the server. Security policies are accepted for traffic so that the firewall can block or allow traffic between the host on the public network and your internal server.

SSH Decryption

SSH Decryption is used to detect and decrypt incoming and outgoing SSH traffic. If an SSH tunnel is detected, the SSH connection is blocked not to be used to tunnel unauthorized applications and other content.

Proxy

A proxy is an intermediary in communication between a client and a server. The proxy takes the package from the client and recreates it again towards the client. In the case of encrypted communication, a proxy receives an SSL request from a client and instead sends it to a server on the Internet. The same response is downloaded from the proxy server and sent back to the client in the reverse direction. It provides encrypted communication between the client and the proxy and the proxy and server on the Internet.

PKI (Public Key Infrastructure)

PKI solves the problems of secure identification of the public key, using a digital certificate to verify the public key owner. You can see the components of PKI in the picture below:

PKI is a set of hardware, software, policies, and standards used to create, manage, distribute a certificate. All this is necessary for the certificate holder to publicly confirm that he/she is what he/she pretends to be.

Root CA (Certified Authority) is the supreme Authority and provides services that authenticate devices, services, people by issuing a certificate that confirms their identity and public key.

The Root CA authorizes the Intermediate CA to certify or authorize other lower CAs. Each CA has a database with active certificates, revoked certificates, issued certificates, etc.

On the side of end devices, the devices are themselves that keep the certificates issued to them and the private key. Users refresh the certificate database themselves or with the help of software. If CA’s certificate is not in the user’s database, it will receive an unreliable warning message about the site they are visiting.

Configuring decryption

  1. Create 2 self-signed certificates (trusted and untrusted)
  2. Export the trusted certificate and import it to the end-user (computer)
  3. Create a decryption profile (optional)
  4. Create a decryption policy
  5. Check if the traffic is decrypted
  1. Creating self-signed certificates

Device> Certificate Management> Certificates> Generate

The image below shows the steps to create a self-signed trusted certificate

The image below shows the steps to create a self-signed untrusted certificate

  1. Export of self-signed trusted certificate and installation on a client

The image below shows the steps to export a self-signed trusted certificate

The image below shows the steps to install a self-signed trusted certificate on a client

  1. Create a decryption profile

Object> Decryption> Decryption Profile> Add

The image below shows the steps to create a decryption profile. The decryption profile serves to let the firewall know how to treat the traffic being decrypted.

  1. Creating a decryption policy

Policies> Decryption> Add

The image below shows the steps for creating a decryption policy. The policy determines which traffic will be decrypted. The name, source and destination zone, and traffic action (No Decrypt or Decrypt) are defined.

Defining the source of the traffic to be decrypted

Defining the destination to which the decrypted traffic is going

Defining the type of services.

Defining the action to be applied to the decrypted traffic as well as the type of decryption and the decryption profile.

Find and check decrypted traffic in the log section.