SSLlabs test is blocked on decryption with F5 passthrough

[raji_toor]

https://live.paloaltonetworks.com/t5/general-topics/extra-certs-inbound-decryption/m-p/457936

Adding to the previous discussion with same setup where PA is doing decryption and the F5 is doing SSL bridging/offload while proxying for the server behind it. 

If we do SSL bridging/offload SSLlabs test goes fine with PA doing decryption and F5 will present cert. URLs show as domain.com

If we do SSL passthrough where F5 will not present certificate on server's behalf and server itself is responsible for presenting the cert. SSLlabs test gets blocked by our policy to block medium-risk/unkown category. URLs show as IP x.x.x.x.

Server supports 1.3 and 1.2 while on PA we can only do 1.2..on 9.1

Website did work normally in browser

I wonder why is there a change.

[aleksandar.astardzhiev]

Hi @raji_toor ,

It sounds like your server does not use valid SSL certificate, but rather self-signed cert. As previously discussed with PAN FW Inbound SSL decryption, firewall will setup two encrypted connection. Which means for the connection between the FW and the server, firewall will act ask client and wait for the server to send its certificate in order to establish encrypted connect.

I am guessing that server is sending self-signed, or invalid certificate.

Side question - why would you enable URL filtering for inbound traffic? What do you want to achieve with that?

Remember that URL filtering is just biig database with URLs and domains categorization, so you can control what web content is accessed by the users. Ususally you will use URL filtering to protect your users when browsing in Internet (because you cannot fully trust it). But for me it doesn't make sense to put URL filtering on inbound rule, this way you protect public users, from potetial bad content on your own server...You don't trust your own server? 🙂

[nikoolayy1]

As @aleksandar.astardzhiev mentioned you may need to import the CA certificate of the servers inside the Palo Alto device for the Palo Alto to trust the servers.

You can also use the advanced SSL decryption logs that are now available:

How to Implement and Test SSL Decryption - Knowledge Base - Palo Alto Networks

Decryption Log (paloaltonetworks.com)

As I also work with F5 , you can check the setting in the server side SSL profile "Untrusted Certificate Response Control" and "Expire Certificate Response Control" as if the F5 is not checking the Server SSL cert then this will explain why it works.

Overview of the Server SSL profile (11.x - 16.x) (f5.com)

[raji_toor]

@aleksandar.astardzhiev We are not using self signed cert. All 3 in the chain Firewall. F5 and Server have public cert on them in this scenario.

And regarding applying URL filtering on own webservers, you can say i am simply satisfying the BPA, but it does provide a good purpose if we donot want our server hit with IP and must be accessed by domain name only..And this is exactly what is happening here.

[aleksandar.astardzhiev]

---

@raji_toor wrote:

And regarding applying URL filtering on own webservers, you can say i am simply satisfying the BPA, but it does provide a good purpose if we donot want our server hit with IP and must be accessed by domain name only..And this is exactly what is happening here.

---

And if your website is not that popular and PAN URL database doesn't have proper categorization for it (like unknown) or you introduce new website and it is categorized as newly registered domain, you will block your user to reaching the page.

BPA should be used to give you directions, it should not be followed blindly.

And what is the problem for accessing the site by IP not by domain name?

Still doesn't make sense for me to use URL filtering for incoming traffic. Again you are trying to protect external users from your own content...

[raji_toor]

@aleksandar.astardzhiev I have never come across issue where PA does improper categorization for our subdomains in last 7 years and new do keep popping up every now and then and we have close to 50. Even if it did new subdomains got through testing phase before and it would come to light then and can be resolved. And I see these as someone not following proper channel to come to our websites and thus see no harm in stopping them as in screenshot below.

We can agree to disagree on this, but my initial question still remains why changing to SSL passthrough on F5 does PA see them coming as https://x.x.x.x and not https://domain-name, where as traffic from same sources during test with F5 VIP as SSL offload or SSL bridging this is not an issue.