SSL inspection and threat prevention

[Charlie80]

I'm considering to enable the inbound SSL inspecition on my intranet cluster.

All rules that allow traffic from untrusted network like plant, supplier etc to the DC have a security profile with vulnerability protection.
But at the moment a lot of traffic is crypted (ssh, https etc) so the firewall can't inspect for CVE right? This means that if a server have a bug covered with a CVE with HTTP traffic the Fw can block in case of the CVE is in prevent but can't do the same for a HTTPS right?

So for a webservices that have a HTTPS to increase the security we have to inspect the traffic with the vulnerability protection but to do that I need to enable the SSL inspecition. It's correct?
How can I estimate the additional load to the CPU?

[TomYoung]

Hi @Charlie80 ,

You are correct.  If the NGFW cannot decrypt the traffic, it cannot inspect it for AV, most vulnerabilities, etc.

Generally you do not have to worry about CPU load unless your CPU is mid range to high now.  Your max throughput will go down.  Your PANW SE can give you the numbers, but threat prevention throughput (which I like to call threatput) minus 30% is a good estimate in my opinion.

Thanks,

Tom

[OtakarKlier]

Hello,

Several things to keep in mind. Some traffic does not like to be decrypted and will break. The ssl certificate you utilize to decrypt the traffic may not be valid to the source device, hence detecting a certificate mismatch (man in the middle, yes this is what the Palo Alto is doing) and may break the traffic.

Honestly the only way to be sure is to try it out in a maintenance window and see what happens.

Regards,

[BPry]

@Charlie80,

One thing you could do is apply it solely to a subset of users at once and see if anything breaks, instead of doing it in a maintenance window or worrying about testing everything before people get back into the office. That way you can limit the impact to known individuals and potentially just a "pilot" group of users if you have that setup in your environment. 

[Charlie80]

honestly the 99.9% of the webservices are HTTPS, so don't use the SSL inspection means don't protect the services esposed to internet where the attacks coming from.
If the PA can break the traffic what's the best solution? don't protect the HTTPS web services or enable the ssl insp.?

[Adrian_Jensen]

If I understand your original question correctly, if you are performing inbound SSL decryption (from internet clients to your own DMZ'd servers) you shouldn't have any problems as your control the servers and can make adjustments to the security as needed.

If you are performing outbound SSL decryption (from your internal clients out to internet servers) you can run into problems with some websites that do high security things like pinned certificates, client certificate authentication, etc. There are also some cases where websites use broken TLS/encryption combinations that cause decryption errors. Most often these affect websites like .mil, government regulation websites, core financial centers, etc. In those cases you can continue to use SSL decryption for everything else, just bypassing decryption to those particular problem FQDNs or IPs.

[TomYoung · Accepted solution]

Hi @Charlie80 ,

@Adrian_Jensen makes a good point.  Best practices for outbound SSL decryption includes a no decrypt rule for certain categories such as "financial-services, health-and-medicine, government, and any other categories you don’t want to decrypt for business, legal, or regulatory reasons"  https://docs.paloaltonetworks.com/best-practices/9-1/decryption-best-practices/decryption-best-pract...

It also says you can add sites to the built-in SSL Decryption Exclusion list.  If you click on the Decryption Best Practices link at the top, you will also see guidance on planning your configuration.  A critical piece is to "Work with and educate stakeholders such as legal, finance, HR, executives, security, and IT/support to develop a decryption deployment strategy."

Thanks,

Tom