I’ll admit that the world became a safer place when the majority of websites started using SSL/TLS encryption by default years ago. The basic level of protection that ensures all of our information is protected is a change that makes everything better for users that don’t know to look for the little lock icon or verify that their banking info is just being transmitted in cleartext. The logical side of me welcomes the fact that we’re all in a better place for information exchange.
The other side of me is disappointed that all this new TLS default communication makes it harder to do things like traffic analysis without getting messy. We can no longer just block secure connections or only allow them on a site-by-site basis. Those options went out the door over ten years ago. Today, we’re faced with even more challenges. The old methods we’ve used in the past to examine traffic are no longer capable of being used in newer versions of the protocol. Worse yet, they don’t scale at all. With our perimeter devices already being overloaded with traffic in an ever-increasing need to send everything to the cloud, we couldn’t keep up with an edge-based solution even if we wanted to!
The old approach of man-in-the-middle (MITM) key rewrite was fraught with problems anyway. The firewall would crack open the packets, re-encrypt them with a new key, pass them along to the destination, and then do the same operations in reverse to send them back. As you can tell from even the most basic description, that’s a very complicated problem for any device. When you add in the new protections introduced in TLS 1.3 to prevent most MITM from happening, you know now why analytics vendors and security teams are apprehensive about making the protocol more resistant to these kinds of approaches. Is there a solution out there that doesn’t require massive rewrites while still keeping our users safe?
Keys to Your Kingdom
I wasn’t sure what the answer to that question was going to be until I sat down to talk to the folks from Nubeva. They’re all over the solution to this particular problem. Walking into my conversation with them, I wasn’t sure how they were going to pull it off, given the number of ways that TLS is being hardened against those that might want to peer inside. I should have known that Nubeva already had a good answer to this problem.
TLS uses session keys for information encryption and exchange. You encrypt your traffic for a particular session with a particular key. When the session is over, you rotate the key and move on. That’s how you prevent attackers from guessing the key and decrypting the packets. Only the sender and the receiver know the session key. If you knew the session key, you could decrypt their packets, right?
That’s where Nubeva started their research into things. They have a software agent that lives on the host server that can pull the session keys from memory. Once you have those keys, you can pass them along to devices that you want to be able to decrypt the traffic. Say you have a firewall doing DPI that needs to open up traffic from a specific host internally for application acceleration. You can configure Nubeva to pull the session keys from the server and forward them to the firewall to do what needs to be done on a session-by-session basis. That means you can exclude sensitive traffic as well, such as bank transactions or protected exchanges.
Nubeva can run on just about anything right now. They told me that running their software in a container on an M1 Mac can scale to around 18Gbps/sec of throughput of session decryption. That’s not shabby for a consumer machine. Want to throw more horsepower at it for lots of TLS work? Clustered ARM cores can scale over 100Gbps/sec. And because Nubeva pulls the session keys into a database, you can scale out horizontally if needed. Let’s say you’re working on a cluster of load balancers and you need to pass session key info across them all for one reason or another. You can easily make that happen with their setup and ensure you have visibility into all that traffic without having to replicate steps across every unit.
Better yet, this solution scales into the future because it works without MITM or passive key intercept. As the developers of the protocols harden them more and more, you have to worry that your current decryption trick is eventually going to be patched out of existence. With Nubeva, you just have to grab the session key when you want it. The process is straightforward. You do have to own your infrastructure in order to make it happen because there is a driver that must be installed on the server to pull the keys from memory, but given the number of organizations that are developing their own custom apps, this isn’t as big of a deal as you might think. It also gives your users a sense of security since you can’t open packets they might not want you looking at.
Bringing It All Together
Security is objectively good. Despite the fact that it can make our jobs more difficult from certain perspectives, I think we can all agree that making things more secure and more resistant to getting hacked makes for a better world. Nubeva’s approach to TLS decryption that doesn’t rely on insecurities like MITM intercept makes me happy because it shows that you can do traffic analysis and security at the same time without compromising.
If you’d like to learn more about Nubeva and where they can help you with your visibility issues, make sure you check out their website at http://Nubeva.com
