ssl inbound inspection in a reverse proxy scenario

[LeonardoMachado]

Dear Community,

I need to configure ssl inboud inspection in a scenario with 5 web services running behind a reverse proxy.

The flow of traffic is as follow:

Internet (same_public_ip) =>> PA ==(nat)=>> Reverse Proxy =>> Web Services

Since PA will not be able to peek into the sll traffic to grasp which one is the aimed internal service to apply the right certificate (and open the traffic), I guess that in this scenario I would have only two choices:

1) Attribute one public ip for each single internal services (and NAT them back into the same reverse proxy)

2) Remove reverse proxy (since PA would be much more efficient on analyzing the traffic than our reverse proxy)

Am I right on these considerations?

Any help would be appreciated.

Thank you.

[aleksandar.astardzhiev]

Hi @LeonardoMachado ,

I haven't personally tested (and at the moment I don't have the resources to do it), but I believe you should be able to have separe Decryption rules and applying different certificate.

As you know Decryption policies/rule are working pretty much like normal firewall rule - firewall evaluating the rules top to bottom search for first match based on given information - source/dest IP, dest port, and custom URL category.

I would assume that you can do the following:

- Let say we have three servers behind the reverse proxy - a.example.com, b.example.com and c.example.com

- Create three SSL decryption rules matching destination IP the public IP of the reverse proxy (before the NAT)

- For each rule define dedicate custom URL category that will match only the FQDN for the specific site - (one URL category for "a.example.com/", one url category for "b.example.com/" and one url category for "c.example.com/")

I am imagine that when inbound connection is received it will probably match the first decryption rule (based on destination IP). When client send the "Client Hello" message during SSL negotiation, firewall will use the SNI to identify the actual requested URL and will use it as URL category match, which will trigger new policy evaluation and with the new information it should match only the one with the correct custom URL category and reply to the custmer with the corresponding certificate.

But as I mentioned, this is what would expect to happen, but not able to confirm. So it will be intersting if you have any way to test it and share the results.

Another approach - simpler but costlier - consider the use of wildcard certificate. In this case you can have single decryption rule (without the need of URL category, only dest ip and port) applying certificate *.example.com. So no matter which of the three services the user is requesting they will receive the same wildcard certificate.

The advantage of this approach is that it simplies your certificate management - you only need to renew single certificate and you don't have to make any changes on the FW when introducing new services behind the proxy

The disadvantage is that wildcard certificate could cost more.

[LeonardoMachado]

I'll try to use the SNI field from the TSL Hello Package to create a new application. Then, I will use this new "application" to differentiate traffic and create a specific decrypt policy.

I'll let you know if it works.

Thank you. 

[aleksandar.astardzhiev]

Hey @LeonardoMachado ,

Defining custom application using the SNI is actually really great idea. It should have the same effect as using default ssl application and custom URL, but this probably will provide better overview.

Just don't forget to add the custom applications to the allow security rule.

I am interested in the final result, keep us posted.

[LeonardoMachado]

This solution to segregate the inbound traffic using a custom application based on do SNI field of the TSL Client Hello cannot be configured.

The Decryption Policy configuration window does not have the Application tab which would allow me to specify only the newly created application to be decrypted. I wonder why PA does not allow decryption policies to be further limited to specific inbound applications.

[LeonardoMachado · Accepted solution]

The solution is quite easy: Decryption Policy accepts URL Category. I have created a custom category with my URL and voilà!! No application needed.

THnks!