SSL Decryption Series: Next-Generation Firewall Buying Criteria for Your Decryption Needs

In my last post, I discussed why NGFWs are the most suitable devices to decrypt traffic, providing several advantages. However not all NGFWs are equal, and unfortunately, it can be difficult to distinguish between firewalls with similar claims. It is important to have clear guidelines for evaluating an NGFW prior to purchase. This will ensure the firewall can support a comprehensive breach prevention strategy, which includes SSL decryption.

Here are the criteria to compare the SSL decryption capabilities of NGFWs:

1. Granularly choose what to decrypt: Privacy concerns and regulations require that your NGFW can selectively decrypt traffic based on criteria flexible enough to meet your needs. These criteria can include user; URLs; URL categories, such as finance or health; externally hosted URL lists to comply with regulations; IP address-based source and destination; ports; and protocols. To catch potential malware, the firewall must also allow you to exclude applications from decryption when they are running on their default ports but continue to decrypt those same applications when they are detected on nonstandard ports.
2. Exclude applications that may break upon decryption: Application vendors sometimes use HTTP Public Key Pinning, also known as certificate pinning, to resist impersonation by attackers using wrongly issued or otherwise fraudulent certificates. When this technique is used, network security devices may break some applications upon decryption. Your NGFW must allow you to exclude such traffic easily by using hostname of the website or application in the exclusion rule. If the NGFW forces you to define exclusions based on distinguished and common names of certificates, it is too complex. To make it even easier, the NGFW should ship with predefined exclusions for well-known applications that break upon decryption.
3. Enforce certificate status: You may want to drop traffic for which the SSL certificate is expired, the server certificate issuer is untrusted or the certificate has been revoked. Your NGFW must allow you to accept or deny traffic that meets any combination of these criteria.
4. Enforce cipher suites: Cipher suites include key exchange algorithms, such as RSA, DHE and ECDHE; encryption algorithms, such as 3DES, RC4 and variants of AES; and authentication algorithms, such as MD5 and SHA variants. The NGFW must support multiple cipher suites and allow you to enforce those that meet your security requirements. You should be able to choose whether to allow or block traffic that does not meet your specified cipher suites.
5. Enforce protocol version: You may need to enforce the use of specific SSL/TLS versions, such as TLS 1.2. The NGFW must offer flexibility in enforcing specified protocol versions and blocking traffic that uses any weaker version.
6. Integrate with hardware security modules: An HSM is a physical device that manages digital keys, including secure storage and generation. It provides both logical and physical protection of these materials against unauthorized use and potential adversaries. Your NGFW must integrate with an HSM for storing private keys and master keys. Even if your organization does not currently require keys to be stored in an HSM, you may need this functionality in the future.
7. Allow users to opt out of SSL decryption: In some cases, you might need to alert users that the NGFW is decrypting certain web traffic and allow them to terminate sessions they do not want inspected. Your NGFW must allow SSL opt-out so users are notified that their session is about to be decrypted and can choose to proceed or terminate the session.
8. Decrypt outbound and inbound traffic: The NGFW must be able to decrypt traffic in both directions so you have the flexibility to deploy it in front of users or your web servers to decrypt outbound or inbound traffic, respectively.
9. Decrypt SSH: Most traffic on the internet is encrypted via SSL/TLS. However, Secure Shell, or SSH, can also be used to encrypt and tunnel traffic inside your network. For example, some internal data center applications may use SSH, which is allowed by policy. To prevent users from using SSH to evade your acceptable use or threat prevention policies, your NGFW must support decryption of SSH traffic that meets your criteria.
10. Use hardware crypto acceleration: SSL decryption is very resource-intensive. Your NGFW must use hardware crypto acceleration to maintain high performance while decrypting traffic.
11. Share threat intelligence and stop threats everywhere based on shared threat intelligence: There are cases when the traffic is not decrypted on the NGFW, due to privacy concerns or certificate pinning, for example. In these cases, if the NGFW is part of a platform that acts on threat intelligence gathered from the network, endpoint and cloud, you will still be able to stop threats even if the traffic is not decrypted on the network. Let’s say a threat passes through the network undetected in encrypted traffic and reaches the endpoint. The platform shares threat intelligence between the network, endpoint and the cloud, and advanced endpoint protection based on this shared intelligence blocks the threat before the attack succeeds. In addition, information about this threat is shared with the entire platform to make network and cloud security more intelligent. This is a distinct advantage that an NGFW acting alone cannot provide.

It is best if your NGFW vendor has plans to support the following forward-looking trends, which are likely to become critical:

• HTTP/2: This is a major revision of the HTTP network protocol used by the World Wide Web. It was developed from the earlier experimental SPDY protocol, originally developed by Google. Although the standard itself does not require encryption, most client implementations have stated that they will only support HTTP/2 over TLS, which effectively makes encryption mandatory.
• TLS 1.3: Having been approved by the Internet Engineering Task Force, TLS 1.3 is expected to make all secure internet connections faster and safer. Highlights in TLS 1.3 include faster data delivery, removing non-AEAD encryption and non-PFS key exchange, and dropping renegotiation.

In my next post, I’ll review the security impact of HTTPS interception. In the meantime, please take a look at our recent on-demand webcast and SSL Decryption Whitepaper. I also suggest that you refer to the Firewall Buyer’s Guide for a list of all business requirements your next firewall should address as well as advice on how to create an RFP and a functional test plan to assist in the vendor and product selection process.