Right-Sizing Decryption Functionality for Your Network

Deep observability is increasingly a necessity for any IT team that wants to better secure and manage their hybrid and multi-cloud infrastructure. One key way admins can gain deep observability into what is going on across their networks is by decrypting network traffic, a feature built into many next-generation firewalls (NGFWs) and modern network management tools.

But if you’re using or considering using your NGFW for decryption, you will quickly realize how difficult it is to size your firewall to handle your decryption requirements without compromising network performance. Many network operations (NetOps) teams have already learned how frustrating this tool sizing problem can be as many vendors do not list performance specifications with encrypted traffic and/or use real-world scenarios in their testing.

This blog takes a dive into analyzing the true resource impact of encryption — and then looks at a potentially better alternative to using your NGFWs to decrypt network traffic.

Why Decryption Matters

Network traffic sent over the internet has been encrypted as a matter of common practice for years. But traffic within and across data centers and corporate infrastructures is encrypted as well, particularly as more and more shops adopt a Zero Trust security mindset. NetOps staff have to deal with both encrypted packets flowing both North-South (that is, to and from the internet) and East-West (laterally, within and across their secured perimeter).

From a security standpoint, this encryption is a double-edged sword. It provides a layer of protection for sensitive data as it flows through your network. But it also hides information about network activity that NetOps staff need to know. Malicious attackers who have managed to gain a foothold in your data center can use encryption to mask command-and-control communication, for instance. To gain visibility into that traffic, NetOps has traditionally turned to various decryption tools — but these tools are up against an increasingly difficult task.

Cryptographic Keys to the Kingdom

The encryption and decryption of network traffic use the SSL/TLS protocol, which is based on what is called the public key infrastructure. An in-depth description of how this works is beyond the scope of this blog post, but what’s important to keep in mind is that data is encrypted and decrypted based on the exchange of cryptographic keys — very large numbers on which the communicating hosts perform mathematical operations.

An attacker can break the encryption if those mathematical operations are too simple, which means that typical cryptographic keys have grown larger and larger over time as compute power has grown cheaper and cheaper; keys today are typically 2,000 digits long, and that size will keep growing. But as those keys grow, decryption becomes a compute-intensive task for legitimate users as well, which has inevitable impacts on network and tool performance. Think of encryption as a delaying tactic. Over time, anything can be decrypted. Encryption is to ensure that by the time something is decrypted it is no longer relevant.

Network tools use two different methods to decrypt traffic of interest to them. These methods are named for their most prevalent use cases. For inbound traffic — that is, traffic from outside your network that is accessing your network resources — an appliance can use your own server’s cryptographic keys to decrypt the traffic and inspect it.

Outbound traffic, which is leaving your network to access resources outside of it, can be decrypted using a more complex procedure known as break and inspect, in which the decryption functionality must stand between the two communicating parties and decrypt then re-encrypt the packets on the fly; this requires more computational power and two network connections.

The key question facing IT is whether the decryption tools they deploy are powerful enough for the tasks they face — or, conversely, if they are overkill (and overpriced) for the level of network traffic they will encounter. The question gets trickier when it comes to NGFWs that bundle decryption capabilities with other functions, as the prospect of replacing an entire firewall to match decryption needs can get very expensive indeed. NetOps needs solid numbers on decryption performance to even begin to answer these questions — but as it turns out, those numbers can be difficult to come by.

Measuring Decryption Performance

The reality is that decryption almost always takes longer and takes more computing power than you would like. That is partly by design — if it were easy to do, then every attacker would do it easily! — but it does make life difficult for NetOps teams who need to decrypt traffic for legitimate reasons.

Just how much of your resources decryption eats up can be expressed by three different measures:

• New connections per second, or CPS. This measures your infrastructure’s ability to perform cryptographic handshakes — the exchange of keys that begins every connection encrypted by the TLS protocol, which is the most computationally expensive part of the process. Larger keys make it harder to create more new connections. CPS is important to measure because if, for instance, you get a flood of web traffic to your storefront and you can’t create connections quickly enough, you could end up losing customers.
• Throughput, or T-put. This is a measurement of how much data you can put through an encrypted connection in a set amount of time. This number can be improved by dedicated chips in your network appliances that perform hardware accelerations.
• Concurrent connections, or CC. This measures how many encrypted sessions your infrastructure can maintain simultaneously. It is largely a reflection of the memory allocated to the decryption service. Some NGFWs do not have dedicated decryption hardware, and adding more CCs can degrade the performance of other features.

While all of these measures are useful for NetOps planning, vendors who report them to tout their wares can game them. For instance, some published CPS results are derived from tests with unrealistically small cryptographic keys. Meanwhile, tests of throughput that use big files result in a “happy path” outcome that does not reflect real-world traffic, which often consists of short, bursty communications with a few large flows in the background.

One organization is stepping up to try to make unbiased scoring possible to help NetOps teams evaluate decryption tools. NetSecOPEN.org is an open-source group working to develop a modern network and TLS performance RFC, which can offer a standard for performance benchmarking. Ciphers, get sizes, and data patterns are all prescribed in a universal format. The following tables compare the decryption performance reported on the spec sheets of various NGFWs to the NetSecOPEN tests.

* The delta represents the performance reduction with encrypted traffic as measured by NetSecOPEN testing.

In general, vendors do not publish encrypted performance numbers in great detail. There are also no universal standards for performance testing, which highlights the sizing challenge.

Addressing the Right-Sizing Problem

NetOps has had a long and painful journey with decryption. Since there is no agreed-upon standard for performance reporting, NetOps has been left to pick up the pieces. Reporting numbers accurately to an open standard that can be used with confidence for sizing will help. But even in that case, changes to cryptographic standards and increased key sizes in the medium term may leave users with a decryption functionality that no longer meets their needs as part of a larger “Swiss Army knife” appliance where many of the other functions are still useful.

Alternative: Gigamon TLS/SSL Decryption

There is an alternative way to decrypt traffic for inspection that doesn’t impact tool performance. Gigamon GigaSmart^® TLS/SSL Decryption can offload decryption tasks from your NGFW and lets it do what it does best: protect your organization from attacks and malware.

Furthermore, decryption from Gigamon is more efficient and allows you to decrypt once and share with multiple security tools. It supports the TLS 1.3 encryption standard and can be deployed inline or out-of-band. With Gigamon offloading decryption from your NFGW, you get expanded visibility into encrypted traffic, regardless of TCP port or application, extended NGFW life, and better security against malware and other threats hidden in encrypted networks.