How I Learned to Stop Worrying and Love SSL Decryption

Posted by George Finney on Apr 22, 2019 1:45:06 PM

Monday, April 22, 2019

By George Finney, Fuel User Group Board Member

As a chief information security officer (CISO) for a university, I sometimes introduce myself in meetings as "Big Brother" to break the ice a little bit. I don't actually read people's email, but I've found getting that kind of issue out on the table early is helpful to building trust. We want our users to know we have well-defined rules of engagement when handling personal information, but we also need them to understand that to provide great security, there can be instances where we need to be a little invasive. Case in point: encrypted traffic.


Gartner predicts that this year (2019), greater than 50% of all new malware campaigns will use various forms of encryption and obfuscation to conceal delivery or to conceal ongoing communications, including data exfiltration. This is a big deal because the signatures next-gen firewalls use, or malware detection services like WildFire, need to be able to read traffic to work.

Encrypted traffic bypasses these controls, effectively rendering them useless. Moreover, according to the same Gartner report, greater than 80% of enterprises’ web traffic is already encrypted, so encryption creates a lack of visibility into your normal, everyday traffic. 

There is a solution to the increasing prevalence of encrypted network traffic in our environments: SSL Decryption. If you’re paying for additional services like WildFire, enabling SSL decryption will allow you to get the most out of your subscription. But this service comes at a cost: increased CPU load on firewalls, concerns about user privacy, and the increased complexity of supporting decryption in your environment. With the right configuration, all of these challenges can be met while increasing visibility and security. Below are some of the use cases for SSL Decryption. As you can see, there are a number of important use cases for protecting the security of our corporate and home networks.

 SSL Decryption_Fig1

Fig. 1 – Next Gen Firewall Capabilities with and without decryption.

To understand how SSL Decryption works, we first need to review how SSL encryption works. Below is a basic example of an SSL key exchange that will begin the process of communication:

SSL Decryption_Fig2

Fig. 2 – SSL Certificate key exchange process.

There are a number of ways to perform SSL decryption, and the Palo Alto Networks Live Community YouTube channel has an overview of the configuration steps. You can use SSL Forward Proxy or SSL Inbound Inspection. The differences are that with SSL Forward Proxy, you are usually acting as a “man in the middle” to decrypt traffic between an internal user and an external server, but this can also be used for internal servers and external users or servers. With SSL Inbound Inspection, you preload the server certificates from your environment and the firewall decrypts on the fly without becoming a proxy. But in either case, the firewall will need to be configured with a certificate so that both client and server can maintain secure communications.

SSL Decryption_Fig3

Fig. 3 – SSL Decryption deployment options. 

There are a number of ways of getting certificates into your firewall.  You can create a new one, update an old one, or import certificates from your load balancer or the server itself.

SSL Decryption_Fig4

Fig. 4 – How to create or import certificates into your firewall. 

The first method, which can be used with the Forward Proxy technique is to create your own self-signed certificate. The disadvantage of this approach is that it will most likely generate a browser warning on any end users that see it.

SSL Decryption_Fig5

Fig. 5- Generating self-signed certificates on your firewall. 

To get around the browser warnings, you can generate a CA cert using a signing request.

SSL Decryption_Fig6

Fig. 6 – Generating certificates on your firewall by using a certificate signing request. 

For SSL Inspection, you can import certificates from existing servers.

SSL Decryption_Fig7

Fig. 7 – Importing certificates into your firewall. 

The process for forward proxy decryption is illustrated below. Note how each side of the firewall will see a different certificate.

SSL Decryption_Fig8

Fig. 8 – Forward proxy key exchange process with a firewall as the intermediary. 

Below is an example of SSL inbound inspection. The original certificate is still used, but the firewall stores a copy and uses this certificate to decrypt traffic as it passes through.

SSL Decryption_Fig9

Fig. 9 – SSH decryption using the firewall with pre-loaded SSL certificates, no proxy required!

As you create your decryption ruleset, you should use the following guidelines:

  • Decrypt everything except sensitive or legally protected network traffic.
  • You should create exception rules for specific zones, IP addresses, users, or URLs
  • You can attach decryption profiles for additional granularity

SSL Decryption_Fig10

Fig. 10 – Setting up your policies for decrypting traffic. 

As mentioned above, some data needs to remain encrypted to ensure user privacy is maintained. User traffic going to banking or healthcare websites should not be decrypted. But for servers that shouldn’t contain any end user data decryption should be applied.

SSL Decryption_Fig11 

Fig. 11 – Careful consideration should be given to what traffic is decrypted.

SSL Decryption will definitely have an impact on the performance of your firewall. To get an idea of sizing, you should follow the following rules of thumb: 

  • Do not size based on decrypt-all performance stats.
  • Calculate % of decrypted traffic
    • Calculate bytes for categories that will be decrypted
    • Calculate total TCP/443 bytes
    • % decryption = sum of bytes for selected categories / total bytes
  • To obtain this report, use Custom Reports and provide this data to your SE

SSL Decryption_Fig12

Fig 12. – Decryption will have an impact on your firewall’s CPU, and this increase will vary depending on the types of traffic your firewall is handling. 

Remember to follow these 6 best practices for SSL Decryption:

  1. Determine the sensitive traffic that must not be decrypted
  2. Add exclusions to bypass decryption for special circumstances
  3. Set up verification for certificate revocation
  4. Configure strong cipher suites and SSL protocol versions
  5. Deploy the decryption certification from your enterprise root certificate authority
  6. Decrypt SSH in addition to SSL

There is a cost to decryption: both in terms of throughput of the device itself, as well impact to the privacy of end users. Because of this, the best practice will be to focus your SSL decryption on the traffic that matters most to your organization. This will reduce the overall throughput impact to your firewalls. But it will also protect your organization from decrypting user traffic that is protected by privacy laws (for example, banking or health care related websites). Encrypted traffic essentially turns your next gen firewalls into out of date legacy firewalls. Enabling SSL decryption ensures that you can keep your next gen firewalls protecting your users at the high level that we’ve come to expect over the last several years. Instead of being perceived as being “big brother”, this will allow you to continue to protect your organization from encrypted threats while protecting the privacy of your employees and customers. 

For further assistance with SSL Decryption, visit the Palo Alto Networks Knowledgebase on SSL Decryption. 

Graphics in this article were sourced from a Fuel event presentation and republished here with permission from the presenter.  

More to Explore

Check out these Fuel blog posts for further reading:

Topics: SSL decryption, WildFire, SSL Forward Proxy, SSL Inbound Inspection, firewall

Posts by Topic

see all

Subscribe to Blog Updates

Recent Posts

Posts by Topic

see all