Inspecting Encrypted Traffic

SSL encryption is intended to make communication over the Internet between two systems private from third-party "eavesdropping." Many websites use SSL to maintain compliance with certain privacy and security regulations, like the Health Insurance Portability and Accountability Act (HIPAA) and Payment Card Industry Data Security Standard (PCI DSS), or as a proactive precautionary service for their users. A large percentage of all network traffic is encrypted with SSL.

Because it's often used and meant to be private between the sender and recipient, encrypted traffic represents an opportunity for attackers to deliver threats into target organizations without being inspected. For example, an attacker may use a Web application like Gmail, which uses SSL encryption, to email an exploit or malware to employees accessing that application via the corporate network or via a company-issued device. Likewise, an attacker may compromise a website that uses SSL encryption to silently download an exploit or malware to the site's visitors.

If you're not decrypting traffic like the kind described in the examples above, you're leaving a large hole in your network where your next-generation firewall cannot protect against threats coming in or sensitive data going out. In addition to ensuring users comply with corporate policy, visibility into encrypted traffic is crucial to confirming that it's clear of cyberthreats.

It's understandable, however, that you may not be able to decrypt all traffic because of the private nature of transactions to and from banking institutions, healthcare providers, government and military organizations, and the payment card industry, for example. However, you can use your next-generation firewall to selectively decrypt incoming and outgoing traffic that falls outside of personal or confidential traffic parameters set by company policies or government regulations.

Palo Alto Networks® Next-Generation Firewall (NGFW) allows SSL decryption on selected incoming and outgoing traffic, providing full visibility, threat inspection and policy compliance before re-encrypting and allowing it to proceed to its destination.

A Phased Approach to Inspecting Encrypted Traffic

Whether you've recently started implementing Palo Alto Networks products or have been administering them for years, make sure you're maximizing their full value by reviewing our best practices for inspecting encrypted traffic.

As with any technology, there is usually a gradual approach to a complete implementation, consisting of carefully planned deployment phases meant to make the transition as smooth as possible with minimal impact to your end users. With this approach in mind, we've recommended our decryption best practices in three phases, each building on the recommendations before it. The ultimate goal for your NGFW implementation should be to end up with granular visibility and full inspection into as much traffic as possible to prevent threats. Robust decryption processes and policies based on your organization's security and privacy needs are required to achieve this so that you end up with a very small amount of uninspected traffic or, ideally, none at all.

When deciding whether or not you want to decrypt traffic, consider your risk tolerance versus user impact tolerance. For example, how many support calls are you willing to accept from frustrated employees that a decryption profile may potentially cause versus how likely that traffic category is to contain threats and how much risk you're willing to accept.

Phase 1: Application Visibility

Before traffic decryption through Palo Alto Networks next-generation firewalls can happen, you must first consider your ability to provide a certificate authority (CA) with which the firewall can establish trust. A CA makes sure that certificates used to enable encrypted communication aren't fake, outdated, or malicious and provides your NGFW with the keys to decrypt it.

If you've got a PKI (Public Key Infrastructure), or internal certificate authority, then the difficult part is already done. If you don't have a PKI, then there's some additional setup work that needs to be done.

PKI Environment:

Use this environment to generate subordinate certificate authorities, or sub-CAs, and deploy them on your firewall. If your PKI is already established, you can manage, distribute, and control trust certificates through it.

Figure 1: Validate against OCSP or CRL servers to check for revoked certificates

PKIs typically include certificate revocation lists (CRLs), which list certificates that have been revoked for reasons that include improper issuance by the certificate authority (CA) and private keys that have been compromised. PAN-OS® can check for certificate status through CRL servers, as well as through Online Certificate Status Protocol (OCSP). Enable certificate checking within the decryption settings on the firewall to check for revoked certificates and block access to applications that use them.

Figure 2: Two modes of decryption within the NGFW

No PKI Environment:

You'll need to use a self-signed certificate and deploy the trust side of this certificate across all laptops and servers. This method of establishing trust can be difficult to manage, especially if you have a large number of employees in remote locations, because the certificates on those endpoints must also be maintained.

Phase 2: Decrypting Traffic

As mentioned previously, there are several reasons why you may not want to decrypt all traffic. So how do you begin determining what traffic you do want to decrypt?

Because many threats utilize file sharing and social media applications, you may want to start with decryption in these categories. The following is a list of URL categories with which we recommend starting:

  • web-based-email
  • search-engines
  • peer-to-peer
  • shareware-and-freeware
  • social-networking
  • proxy-avoidance-and-anonymizers
  • computer-and-internet-info

Choose a category you want to start with and apply a decryption profile to it. Once you've worked through any associated issues, choose the next category you want to decrypt. Remember to try new decryption policies through a test group first before extending them to the rest of your organization, considering both specific users and destinations (URLs or IPs) that will need to bypass the decryption rule.

The following is a list of sensitive categories that should be bypassed for decryption:

  • financial-services
  • government
  • military
  • health-and-medicine
  • shopping

Eventually, an ideal decryption rule set should have a decrypt-all policy with specific exceptions for sensitive categories and websites with decryption breakages.

Figure 3: Decryption exceptions may include specific source users or groups, destination IPs and URLs, and sensitive URL categories

Though privacy regulations may prohibit you from decrypting certain kinds of traffic, thus forcing you to accept any risk of threats associated with that traffic at a network level, this doesn't mean you cannot still protect your organization. For traffic that you cannot decrypt, apply a rule that alerts you to SSL traffic on non-standard ports so you can investigate and identify legitimate and illegitimate usage.

Phase 3: Establishing A Test Group

Before you start decrypting traffic, review proposed decryption policies with your legal team to make sure you comply with any applicable regulations within the regions where your users are located.

Once you've gotten legal and executive approval to move forward, set up a small group of users on whom to test new decryption policies. This will allow you to understand the impact of your decryption policies and test processes you create for sites that will not decrypt. Implementing Palo Alto Networks User-ID™ technology will help you more easily carve out groups of users to whom you will deploy decryption policies and whom you may need to bypass (legal teams, for example), especially if you already have groups set up within Active Directory.

It's important to keep this test group active even after you've implemented decryption policies across your organization. There may be new forms of encryption for which Palo Alto Networks releases support, and maintaining your test group ensures that you're always prepared to analyze the effect of newly supported decryption with minimal impact to your organization.

Not all encrypted traffic can be decrypted by your firewall, such as traffic using unsupported ciphers or client-side certificates, or applications where the certificate is embedded in the source code, so it's important to figure out how you're going to handle these applications. After you've set up your test group, come up with a process for traffic that you currently cannot decrypt. Make it a habit to review this process on a regular basis.


  • For advanced security, it's recommended that you set up your decryption profiles to be as strict as possible, including blocking connections to websites with invalid or expired certificates and disallowing sessions that can't be decrypted.
  • A URL Filtering subscription to PAN-DB makes SSL decryption much easier to implement because its comprehensive Web categories enable you to make informed decisions on the kinds of Web traffic you should and should not decrypt, especially when navigating around user privacy regulations.
  • Some applications come with their own embedded list of trusted certificates (certificate store) and will not trust the certificate deployed within the firewall. In these cases, you can manually import the certificate on the firewall into the application's certificate store to enable decryption and re-encryption for that application.
  • A category many customers are concerned about is online storage-and-backup because it represents dozens of opportunities for attackers to exfiltrate data. We recommend that you create a custom category that would allow company-sanctioned storage and backup sites, such as Box, Hightail, and Dropbox, and decrypt traffic to and from those specified and approved sites.
  • If there is traffic you're not able to decrypt, consider deploying Traps Advanced Endpoint Protection on laptops and servers. Traps will prevent exploits and malware hidden within encrypted traffic from executing on your organization's endpoints, even when you can't detect them on the network.
  • Keep the culture of your organization in mind when rolling out decryption policies beyond your test group. It may be best to start with the least sensitive departments/
  • groups to understand potential negative ramifications of your policies. Once those have been adjusted for, continue to deploy decryption policies to more sensitive departments/groups.
  • Create a custom URL category, "No Decrypt," and place URLs that fit this profile into that category. This will make it easier to keep track of these URLs and apply decryption policies as cipher suite support becomes available instead of having to manually track them.