Don't be fooled by imposters and impersonators!
Time to read: ~9 minutes 30 seconds
TLDR: Passive, out-of-band decryption for perfect forward secrecy in TLS 1.2 and 1.3 exists. It is not only possible, it is also commercially viable at scale. Anyone who says differently is papering over their own technical deficiency. Mirroring already decrypted packet traffic to out-of-band tools is *not* the same as out of band decryption.
Don’t be fooled. Out-of-band decryption for all modern perfect forward secrecy encryption, Diffie-Hellman ciphers and TLS 1.3 protocols exist. Anyone who says otherwise is either outright lying or trying to paper over their own solution’s inability to handle modern encryption.
PFS - perfect forward secrecy - is everywhere now. It is widely deployed in TLS 1.2 today. It is required in TLS 1.3, which is actively rolling out. PFS eliminates packet visibility for older decryption systems like those present in packet brokers. Older packet brokering and decryption solutions that could handle TLS 1 and 2 are unable to deal with the ephemerality and forward secrecy capabilities of modern encryption. So they obfuscate and misdirect about what their products actually do. They use the phrase “out of band” and “passive” to describe possible inspection and detection tool architectures, which intentionally confuses out-of-band decryption capabilities offered by truly innovative solutions.
We recently saw this at work as some of the bigger players in the space began talking about passive decryption and out-of-band inspection. The truth is that they still terminate and decrypt inline, then mirror or broker those decrypted packet streams to IDS and DPI tools sitting out of band. Out-of-band inspection is not out-of-band decryption.
First, it is important to understand four fundamental concepts:
- How Forward Secrecy encryption works
- How active and passive-inline decryption works
- How passive, out of band decryption for PFS works
- How inspection and detection tool architectures are commonly deployed
How Forward Secrecy Works
PFS, used in TLS 1.2 and required in TLS 1.3, makes encryption stronger. Not only are the encryption ciphers stronger, the final encryption keys are ephemeral - lasting for only a few seconds before a new key is required. This means only the packets in the session from which the ephemeral keys were created and used may be decrypted by those keys. PFS encryption only applies to the packets in the session in which the keys were created. As a result, even in the unlikely event that a packet and its key are intercepted and cracked, that key cannot be used to decrypt and read other traffic. This is a fundamental and important shift from the old-school RSA key exchange that previous decryption solutions required. With RSA key exchanges, the same key was used for a longer period of time to encrypt and decrypt many sessions, requests, traffic and communications between a server and many clients. With new PFS, not only does each client-server pair have its own unique key (keys are not shared) but each key only lasts for a single session (or even more quickly with configuration).
Additionally, and more importantly, the fundamental encryption architecture is different. The advances in PFS and ciphers, like ephemeral elliptic curve Diffie-Hellman, where only the TLS client and TLS server - the participants in the TLS handshake - are able to create and understand the final encryption key. It is this key fact that gives such trouble to old out-of-band decryption solutions like those baked into the big packet brokers. Because they do not participate in the TLS handshake and because final encryption keys cannot be derived from certificates, those old solutions do not work.
How Active and Passive-Inline Decryption Works
Because encryption keys cannot be re-created by certificates, inline decryption is the only option for legacy systems like network packet brokers. In this kind of a setup, the decryption appliance or software is deployed inline, which allows it to participate in the TLS session. Using the final encryption key it generated as part of each TLS session, it is able to decrypt the packet traffic and then re-encrypt it (using either a different cipher or the same one) and pass it along to the next device in the network. Passive inline decryption means that the decryption device may allow a copy of the decrypted packets to be mirrored off to an out of band inspection tool (or a series of such tools).
Active inline decryption typically means that the decrypted packets are passed directly to inline inspection, prevention and detection tools before they come back to be re-encrypted and continue on to their intended destinations. Many legacy network packet broker and decryption vendors talk about passive decryption when they really mean passive inline decryption. In these cases, the decryption is fully inline and all the interruptions, performance degradations, and increased risk and cost overruns associated with inline solutions still apply. When these solution vendors downplay the essential inline aspects of their required architecture, and overemphasize potential passive inspection options, they do a disservice to the DevSecOps space.
How True Passive, Out-of-Band Decryption Works with PFS
Nubeva uses Symmetric Key Intercept decryption to achieve true passive, out-of-band decryption for TLS 1.2 with PFS and TLS 1.3. Nubeva decouples symmetric key discovery from the final act of decryption, which enables true out-of-band decryption with absolutely zero impact on network performance. What’s more, with Nubeva users introduce no risks from passing decrypted content over the wire or downgrading encryption levels. The Nubeva Kubernetes DaemonSet, or read-only Key Discovery sensor, identifies the final symmetric key during the TLS handshake and securely provides it to a decryptor - either Nubeva’s decryptor or your own. With the Nubeva store-and-forward system, the ephemerality of modern encryption keys can be extended for the purposes of regulatory inspection, forensics, detection or any other purpose. Final encryption keys can be preserved as long as needed or flushed as rapidly as desired. Packet mirrors, taps or brokers - including Nubeva’s own mirror capability, create copies of the fully encrypted packet streams and send them to decryptors and security tools. This achieves truly passive, out-of-band decryption. Multiple decryptors receiving the same mirrored packets can each retrieve the same symmetric key corresponding to that packet. This architecture allows unlimited parallel, balanced processing across multiple tools.
How Inspection and Detection Tools are Deployed
Passive, out-of-band decryption can happen with Nubeva TLS Decrypt and its Symmetric Key Intercept approach. IDS, DPI, APT and monitoring tools are often deployed out of band, doing their work on copies of network packets. This out of band, passive tool deployment allows inspection, detection, monitoring and forensics to proceed without impacting network performance or introducing latency. In an active, inline deployment of tools, prevention is possible since network traffic is effectively sequestered while it is being tested and inspected. Simply having out-of-band tools is not the same as doing out of band decryption.
Let’s see why that matters.
These are the top three reasons out-of-band decryption is more important than out-of-band inspection.
- PFS obsoletes legacy out-of-band decryption.Older, out-of-band decryption solutions that relied on certificates to recreate encryption keys are obsolete. With forward secrecy only the TLS client and TLS server have the final encryption keys. Older decryption systems relied upon their ability to recreate encryption keys in order to decrypt sessions. That ability has evaporated with PFS in TLS 1.2 and 1.3.
Solving for forward secrecy. The only out-of-band solution is to discover and retrieve the keys from the client or server with a process called Symmetric Key Intercept. Symmetric Key Intercept effectively decouples key discovery from packet capture/mirroring from decryption.
- Inline decryption is not tolerated in modern architectures.
Inline decryption requires that it terminate the TLS sessions in order to have access to the final encryption keys. A legacy network edge or gateway setup would perform a terminate - decrypt - inspect - reencrypt - forward process. If you read closely, this is exactly what legacy packet brokers describe. They decrypt in-line and then mirror the decrypted packets to out-of-band tools for inspection and detection while re-encrypting the original session traffic and sending it on. Not only does this process introduce risk, it is also incredibly inefficient. This process simply crushes packet broker and firewall performance (the traditional locations for inline decryption). NSS Labs discovered SSL decryption degraded the firewall performance by as much as 80 percent and reduced transactions per second by 92 percent. Furthermore, edge-based decryption makes no sense in modern architectures. There simply is no edge anymore. Or, said another way, everything is an edge and dropping expensive (and 92% inefficient) hardware chokepoints everywhere is not only silly, it is prohibitively expensive. Relying solely on ingress traffic from your own network is an example of a devastatingly incomplete security solution architecture. It ignores pinned certificates. It ignores all East-West traffic. It ignores all API traffic to third-party services and clouds.
Solving for modern architectures. The only practical solution is a modern out-of-band decryption solution that decouples key discovery from packet mirroring from the actual act of decryption. A Symmetric Key Intercept decryption solution does exactly this and is the answer to bring back true, out of band decryption even in modern architectures.
- There’s no middle in modern and elastic environments. This is not the only problem faced by inline decryption. As the in-line vendors are finding out, there is no middle in modern architectures like clouds, Kubernetes and microservices compute environments. Modern compute environments are highly elastic and enable resources to spin up, execute and spin down in microseconds. Inside Kubernetes clusters the entire concept of networking is a completely different animal with fixed IP addressing being non-existent. This means solutions that rely on pre-known IPs and locations are completely unable to work in these kinds of environments. ignoring the problems doesn’t make them go away. Pretending like East-West visibility, inter- and intra- Kubernetes and container traffic visibility is unimportant is simply bad advice. Pretending like decrypted visibility only at an ingress edge is sufficient is wrong-headed.
Legacy solutions that pretend their increasingly shrinking footprint is all you really need are doing the IT and Security and DevOps communities a huge disservice.
Solving the modern middle. The only practical solution is a Symmetric Key Intercept solution that is able to run as a Kubernetes DaemonSet, container based read-only sensor (not an agent), a windows or native linux service and in hypervisor environments. This solution is fully modernized to understand, identify and automatically learn and recognize TLS sessions wherever they occur, not just on TLS servers. The decoupling of final, ephemeral, PFS key discovery from packet mirroring and decryption enables security teams and tools like IDS, DPI, APT and anomaly detection processes to regain full decrypted visibility to packet traffic wherever it comes from. This includes all PFS, all pinned certificates, all Diffie-Hellman based ciphers, all TLS 1.2 and TLS 1.3.
The reality is that fully passive, out-of-band decryption is available, at scale today. Nubeva is the only fully open, out of band, complete PFS decryption and mirroring solution that handles all architectures and elastic environments. Nubeva doesn’t pull a “fast one” by talking about out-of-band tools. Instead, our patented Symmetric Key Intercept technology decouples key discovery from packet mirroring and decryption.
This approach lets enterprises extend the ephemerality of modern encryption keys long enough to use them for security inspection and detection, then remove the keys for good. Enterprises can separately mirror the fully encrypted packet streams to any number of inspection and detection solutions. There, the packet streams may be decrypted by the Nubeva decryptor or a firm’s own decryptor. The ability to retrieve the discovered symmetric keys via API or via Nubeva’s decryptor means that massive parallel scaling is not only possible, it is affordable.
Indeed in modern elastic environments, this is the only solution that makes sense. Anyone saying differently is hiding their own deficiencies and doing you a disservice. Do not be fooled.