We have answers and resources. A digest of decryption materials to keep you up to date
Time to Read: 7 minutes, 50 seconds
TL;DR - In this post, we answer questions like:
- Why do I need to look at traffic in the first place?
- TLS 1.3 may improve security and performance, but it complicates my ability to see beyond flow logs and headers. What are my options?
- Why does enabling decryption in my firewall or proxy kill performance? What is the most taxing part of decryption?
Get answers to these questions and more.
With so many IT security and DevOps professionals working from home, now is the perfect time to stay educated about the latest developments in decryption visibility, new encryption protocols and distributed compute network environments. We encourage you to bookmark this page and keep coming back to refresh your knowledge about how to ensure your cloud and data center environments remain secure. New protocols like TLS 1.2 with perfect forward secrecy, TLS 1.3, certificate pinning, and accessing internal Kubernetes or container-to-container traffic present some challenges. How can you gain access to the visibility you need when monitoring and threat hunting network traffic?
With this in mind, here are a few common questions (and answers with resourced and referenced information) that will help you in your fight to see detailed packet information.
Got a question you’d like answered? Let us know by clicking on the chatbot or sending us a note.
Q: Why do I need to look at traffic in the first place?
A: When you understand that the majority of modern threats are hidden inside encrypted packet data, you quickly realize there is a need to look deeper at the traffic between servers and in and out of your cloud subscriptions. Traffic metadata and header information can be reviewed by some systems, but modern malware is hidden inside the pieces of information flowing between servers and inside your cloud. Do security teams need to examine this traffic at the packet level? Security experts say yes. According to Ponemon, “Visibility is important to creating a strong security posture. Investing in visibility and discovery solutions is an opportunity to reduce cybersecurity risks.” Furthermore, according to a recent EMA study, “Respondents using packet capture had higher confidence in virtually every [cybersecurity and compliance] control identified.” The data and answer is clear, visibility into network packet traffic is vital to protect organizations and help ensure compliance. Nubeva agrees. The challenge is ensuring visibility of packet data even with ubiquitous encryption. We created Nubeva TLS Decrypt to allow users to see any and all traffic without disrupting network and application performance. Nubeva has created the only fully out-of-band decryption and mirroring solution that works with modern encryption standards like perfect forward secrecy - PFS - elliptic curve Diffie-Hellman ephemeral encryption ciphers - ECDHE - and TLS 1.3. We created Nubeva mirrors to send copies of the traffic to the tools you use to monitor anomalies and threats.
LEARN MORE ABOUT NETWORK PACKET VISIBILITY WITH NUBEVA TLS DECRYPT: In this video, we provide a short explanation of how Nubeva TLS Decrypt works in conjunction with Amazon VPC Traffic Mirroring.
Q: TLS 1.3 may improve security and performance, but it complicates my ability to see beyond flow logs and headers. What are my options?
A: The bottom line is this: The newly adopted TLS protocol enforces perfect forward secrecy (PFS) which makes encryption keys stronger, ephemeral — keys last for only a few seconds or minutes before a new key is required – and ensures encryption only applies to the packets in the session in which the keys were created. This means that even in the unlikely event a packet and its key are intercepted and cracked, that key cannot be used to decrypt and read other traffic. Modern decryption for PFS and TLS 1.3 require mirrored packet traffic and the symmetric encryption key. With our Nubeva TLS Decrypt solution, users can work with any tool and any packet source to discover the symmetric encryption keys from working memory during the TLS Handshake from or to any workload. With this solution in place, security tools receive both the originally encrypted and fully decrypted packet streams. Important encrypted stream metadata is preserved for analysis and fingerprinting, while the decrypted streams are made available to the tools for inspection.
LEARN MORE: We recently published an ebook, “Why Modern DevSecOps Needs Decrypted Visibility,” in which we address both a) the pros and cons of TLS, and b) how to decrypt traffic in public and private clouds and datacenters.
Q: Why does enabling decryption in my firewall or proxy kill performance? What is the most taxing part of decryption?
A: To decrypt or gain direct visibility to encrypted network traffic, security teams must replay, reproduce or engage directly in the TLS handshake. Then they must make a duplicate of the packets to mirror or re-create the session in order to continue it - for instance in a forward proxy situation. When using a man-in-the-middle architecture, this process impacts compute performance and increases the real cost needed to decrypt traffic (more CPU, human resources, etc.). With the ephemeral nature of forward secrecy in TLS 1.2 and 1.3, each session (or even parts of sessions) is separately encrypted requiring an exponential multiplier on resources for MITM systems that must terminate and re-create sessions. The ability to re-play sessions with certificate information (i.e. legacy out of band decryption from packet brokers or hardware decryption vendors) is eliminated with PFS. That leaves the only option for traditional in-line systems: to participate directly in the original TLS handshake, inspect the traffic, then create another TLS handshake with the destination system in order to allow the session to continue. In-line systems must participate in 2 handshakes for every TLS Client “Hello” they receive. Now multiply that CPU load by the explosion of separately encrypted sessions required by PFS and TLS 1.3 and you start to see the enormous compute load put onto systems that are already suffering from performance bottlenecks. Add to this that the TLS Handshake is the most compute intensive part of the decryption process and (the actual act of encryption / decryption is actually very fast) and you can quickly see the challenge for modern, in-line decryption solutions. When those solutions are part of a firewall, forward proxy or other system that needs to decrypt in order to perform its URL filtering and packet inspection, you see how PFS and TLS 1.3 become huge challenges for those systems.
Nubeva changes all that. By bypassing participation in the TLS handshake, Nubeva is able to enable modern decryption and do so out of band, quickly and without disrupting network traffic flows. The entire TLS / SSL decryption process can be offloaded from your inline devices which restores them to peak performance while eliminating sources of latency, packet loss and interruptions. With Nubeva’s solution in place, IT teams don’t need to make new capital investments to decrypt. Nuvbeva TLS Decrypt bypasses the handshake for decryption and relies on Symmetric Key Intercept architecture that enables users to do “bulk” decryption.
Q: My security team already uses several open source tools to analyze network traffic. Can I keep using the tools we have approved to look at decrypted traffic?
A: The quick answer is, “yes.” We created Nubeva Cloud Tools using AWS well-architected infrastructure as code approach to enable you to launch a fully functional, out-of-band decrypted visibility and monitoring suite with a single click of a button. This solution works with open source tools like Wireshark, Moloch, ntopng, Surricata, and Zeek. Getting immediate decrypted visibility in your cloud subscription is easy to launch using our master CFT. This video walks you through a short three-step process to get up and running.
Furthermore, Nubeva decouples key and session secret identification from the process of decryption. Firms can deploy Nubeva decryptors directly onto inspection tools, next to tools, as stand alone decryptors on their own containers in an architected decryption zone. Organizations can also use their own commercial or bespoke decryptors and retrieve keys / session secrets from the Nubeva symmetric key intercept system via secured API calls etc.
Q: What if I already get my traffic from a third party packet broker? Do I have to change how I obtain the traffic I need to monitor?
A: Nubeva TLS Decrypt has a built in packet mirroring service that users can choose to use – or they can continue using their existing packet broker, infrastructure mirroring, hardware or software based taps. Nubeva lets you decrypt traffic from any traffic source. Nubeva’s mirroring capability augments pre-existing packet acquisition solutions. Nubeva delivers the ability to mirror packet traffic out of VMs, containers, and Kubernetes pods. Because Nubeva’s read-only sensors can perform both packet mirroring and key discovery, there is only one system needed which reduces complexity. Nubeva sensors can be deployed as Kubernetes DaemonSets, containers or windows services. This delivers ultimate flexibility and creates visibility for modern, elastic and dynamic compute environments that are not served by legacy packet brokers. Of course, Nubeva will continue to work with infrastructure based packet acquisition like Amazon VPC traffic mirroring and Azure Vtaps. Nubeva can supplement these systems by created packet acquisition and mirroring opportunities where those systems don’t yet reach; for example Nubeva works to mirror packet traffic in non-Nitro compute instances in AWS, a place where Amazon VPC traffic mirrors don’t yet work. Nubeva works in Azure as well to provide comprehensive packet traffic access and mirroring while VTaps are still being worked on by Microsoft.
Nubeva provides a set of open source cloud tools to allow you set up labs and start monitoring if you don’t have packet security tools in the cloud that you already use. Watch this short video to learn more about the services Nubeva TLS Decrypt delivers.
What additional questions do you have? Connect with us at firstname.lastname@example.org