Episode Transcript:
Hello everyone and welcome to another episode of PANCast! I am going to start today with a question: When was the last time you visited a public website that was using non-secure HTTP? I am guessing it was probably a long time ago.
The majority of web traffic on the Internet is now HTTPS so it uses SSL, or TLS to be more precise. This is to provide security for the connection. This means without SSL decryption, you do not have visibility to a very large portion of data going through your firewalls or Prisma Access. Threat actors are increasingly using encryption to be able to hide malicious connections and also to be able to deliver malicious content without it being picked up by security appliances. Aside from the potential for this malicious activity, it also means we only really have limited visibility of what a user is doing. Once encrypted, what happens after the session is established cannot be known. Today we’ll go through SSL decryption which gives you back that visibility.
John Arena is a Professional Services Consultant with a background in Technical Support for Palo Alto Networks and a passion for educating and sharing knowledge with customers.
So what is SSL decryption — also known as SSL inspection — and how does it work? Most Internet traffic these days uses SSL so it is encrypted. Therefore when the session passes through a firewall, it has no visibility into the session so cannot do any additional layer-7 inspection. SSL decryption allows the firewall to decrypt and inspect the traffic. This ensures that not only do you have full visibility of what the session is, but you can also do threat inspection such as protecting against malware and also blocking attempts to exfiltrate data. It works by doing what is called man in the middle so the firewall will have an SSL session to the client and then a separate SSL session to the server. This allows the firewall to see what traffic is going through the encrypted session.
On Palo Alto Networks firewalls, we support both outbound and inbound decryption with outbound being the more common one. This is used to inspect traffic from your internal network to the Internet. This is also what would be used if you enable SSL decryption on Prisma Access. Inbound decryption is used when you are hosting services and you want to also inspect any traffic coming from the Internet to your public facing servers. Today we will discuss outbound as this is more common in inspecting traffic from users to the Internet.
Hopefully you now understand why we need SSL decryption, let’s talk about configuring it and more importantly what you should know before you do.
If you are currently not doing SSL decryption on your Palo Alto Networks firewall or on Prisma Access, then before you rush in and enable it, I want to discuss a few things you need to be aware of.
Let’s start with a bit of planning.
While in an ideal world, we would decrypt all traffic passing through the firewall, unfortunately this is not possible. So, the first thing is to have an understanding of what traffic you can and cannot decrypt. There are two main reasons you would have to bypass decryption for certain traffic: Number one, legal or regulatory reasons. You may not be able to decrypt certain user traffic under your local laws, for example banking sites. The second reason is for technical reasons. Not all traffic can be decrypted unfortunately. Some security related mechanisms, like certificate pinning or client certificate authentication mean we cannot decrypt those sessions. Some applications even use proprietary encryption so again these cannot be decrypted. In both of these cases you need to bypass decryption for that relevant traffic.
There is a great deal of flexibility in how you can choose what traffic to decrypt and what to bypass. I won’t go into the details as we have specific Knowledge Base articles on the topic. Our best practices guide also covers these details but what is important is you need to be aware there will be some traffic you will need to bypass.
Now that you have details of what you can and can’t decrypt there is another important thing to consider. SSL decryption does use processing power. Let’s discuss. You currently do not have SSL decryption enabled and traffic is working fine through your firewall. At a low level, this is what happens. A new SSL session comes into the firewall. We inspect the SSL handshake and can do some control based on that but as soon as the encrypted session starts, the traffic just passes through. Because we can’t decrypt it there is really no processing required. Let’s consider what happens with SSL decryption enabled.
A new SSL session comes in. We do the normal inspection on the SSL handshake but because we are now decrypting, the firewall also needs to set up a session to the server along with the session to the client. This requires additional processing for the SSL setup and also for the decrypting and encrypting process. As you can guess, the processing load on the firewall increases. But that’s not the only thing. Not only do we have the additional processing required for the SSL decryption process but previously the traffic was just forwarded. Now we can decrypt we can also inspect it and again, that takes processing power.
Depending on your firewall model, the amount of SSL traffic going through and also the current load on the device this could mean you see CPU load increase. So before enabling it, know your device utilization. Now what I don’t want is that you come away from this thinking I can’t enable SSL decryption, my firewalls will be impacted. The point is you will need additional resources when you enable SSL decryption so make sure you have done the necessary checks before you do. Along the same lines, plan for a staggered deployment. You can use userID and groups to control which users traffic is decrypted so you can start with a small number of test users initially.
Not only does this help checking for any resource issues but it also means if there are any applications that cannot be decrypted they will be found with a smaller base of users. For those of you using Prisma Access, generally the same things apply. The only difference is the resource utilization. As Prisma Access is a cloud-offered service and we have autoscaling to cover increased load, this should not be an issue in most cases.
OK, so we have covered what to be aware of and how to plan on enabling SSL decryption. I just want to finish off with a few additional details which I think are good to be aware of.
First is certificates, they are very important when it comes to SSL. The full details are probably out of scope of this episode but just be aware you need to have and configure a number of certificates for SSL decryption. The one thing I will say, because I have seen it a few times, is please do not use the same certificate for forward trust and for forward untrust certificate — this defeats the purpose of having an untrust option.
CRL and OCSP are protocols used to check whether certificates have been revoked and add an additional layer of security. Both can be configured and used with SSL decryption.
Next, let's discuss the QUIC protocol. You may have seen references to blocking QUIC on our firewalls. This is again for security. QUIC uses proprietary encryption over UDP so we cannot decrypt and inspect the traffic. By blocking it, the browser will fallback to using SSL and can therefore be inspected.
And finally, even with a no decryption policy, you can still enforce some security by blocking expired certificates or certificates with untrusted issuers.
There has been a fair bit of info in this episode and we didn’t even really get into too many technical details but the main things I want you to remember are:
So, there you have it. SSL decryption is very important these days and if you do not have it enabled, it should be something you're looking into. Remember the transcript and some useful links can be found on live.paloaltonetworks.com under PANCast. Until next time.
Check out the full PANCast YouTube playlist: PANCast: Insights for Your Cybersecurity Journey.
Related Content:
