Palo Alto Firewalls - Decryption Profiles - Advanced HTTPS Inspection (Outbound)

This article is a continuation of the Basic HTTPS Inspection configured in the previous articles “Palo Alto Firewalls - Basic HTTPS Inspection (Outbound) with internal PKI Root-Signed CA Certificate” and “Palo Alto Firewalls - Basic HTTPS Inspection (Outbound) with Self-Signed CA Certificate”.

Introduction

To further control how HTTPS Inspection works for your users in different scenarios, you can configure a custom Decryption Profile and attach it to your Decryption Policy rules.

Using a Decryption Policy, you can configure a variety of additional decryption related parameters, such as blocking your users from accessing websites using legacy encryption algorithms, or from accessing websites with certain certificate errors AT ALL, even if they click on the “Proceed anyway”-button when the error presents itself.

This could be useful for those environments that have a somewhat strict IT security policy in general, where trusted and secure communication must be achieved at all times.

Create a Decryption Profile

To create a Decryption Profile, navigate to OBJECTS > Decryption > Decryption Profile and click on the +Add button at the bottom.

Give your policy a proper name, “CORP-Decryption-Profile” in my case, and go to the SSL Decryption > SSL Forward Proxy section and start going through all the different checkboxes and what they do.

!! Many of the options given here can severely impact your end-users, make sure to read up what each and every one of the checkboxes mean in Palo Alto Network’s official documentation. Even the documentation recommends against using some of these options, as security can be “too good” and stop legitimate network traffic !!

Continue to SSL Decryption > SSL Protocol Settings, where you can block certain algorithms from being used when setting up “secure” connections, as some older legacy algorithms are no longer considered even remotely secure to use.

While I’m not going to give any specific pointer as to what should and should not be checked in terms of these algorithms, I want to at the very least show that the possibility to control this is here.

Click on OK when you are done.

With web browsers getting better and better at improving general security all the time, many of the legacy algorithms are already blocked from being used in most modern web browsers, so using this method would be adding just another layer of security.

Activate Decryption Profile

Now that we have created a custom Decryption Profile, we need to activate it by attaching it to a Decryption Policy Rule.

Do be careful with the pace of implementation when creating and activating Decryption Profiles, as they can cause issues for end-users. There is always the possibility that something unexpected can break, so start small with limited zones/IP addresses and work your way up.

We are going to utilize an already configured Decryption Policy Rule called “HTTPS Inspection Outbound”, which is our catch-all inspection rule, and simply attach the newly created Decryption Profile to it.

Navigate to POLICIES > Decryption and click on the Decryption Rule that you want to change.

Go to the Options section and set the Decryption Profile to your custom Decryption Profile, which in my case is “CORP-Decryption-Profile”.

Click OK when you are done and do a Commit to activate your changes.

Verification Decryption Profile

Verifying your Decryption Policy will of course vary depending on which boxes you checked during the configuration phase.

In my example above, I checked the boxes for “Block sessions with expired certificates” and “Block sessions with untrusted issuers”, among a few other ones.

If I try to access websites suffering from these two issues, the firewall should intervene and send us to a block page instead.

To access a website with an expired certificate, we will visit https://expired.badssl.com

We will still get the typical certificate warning from the web browser, but if we click on “Proceed” to move past the warning, we will be sent to this block page by the firewall.

Similar to the test above, to see what happens if we try to visit a website that has a certificate issued from a root-/intermediate CA that is unknown to the firewall, and therefore untrusted, we can visit https://untrusted-root.badssl.com

We will still get the typical certificate warning from the web browser, but if we click on “Proceed” to move past the warning, we will be sent to this block page by the firewall.

Decryption Profile can also be used with the Inbound HTTPS Inspection and SSH Proxy features of the firewall, but I will leave that to another day.