SSL inspection and threat prevention

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Palo Alto Networks Approved
Palo Alto Networks Approved
Community Expert Verified
Community Expert Verified

SSL inspection and threat prevention

L2 Linker

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?

1 accepted solution

Accepted Solutions

Cyber Elite
Cyber Elite

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

Help the community: Like helpful comments and mark solutions.

View solution in original post

6 REPLIES 6

Cyber Elite
Cyber Elite

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

Help the community: Like helpful comments and mark solutions.

Cyber Elite
Cyber Elite

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,

Cyber Elite
Cyber Elite

@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. 

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.?

L6 Presenter

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.

Cyber Elite
Cyber Elite

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

Help the community: Like helpful comments and mark solutions.
  • 1 accepted solution
  • 3361 Views
  • 6 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!