Earlier this year, during RSA, The Tech Herald sat down with Daniel Proch and Jarrod Siket of Netronome to talk about flow processing, acceleration cards, but most importantly, a transparent proxy for SSL called the SSL Inspector.
When The Tech Herald sat down with Daniel and Jarrod, we knew the basics of what they offered with regard to SSL security. However, what we wanted to learn was how their SSL offerings were different from the others. Netronome offers the SSL Inspector, which is available to security and network appliance manufacturers in a standard SDK (Software Development Kit), or as a part of a range of stand-alone appliances.
SSL Inspector is an extension to the Netronome Flow Manager (NFM) software, which offers deep packet inspection at turbocharged speeds. Adding to the universal abilities of their products, the NFM is supported on all of Netronome’s hardware acceleration offerings, including the Netronome Flow Engine (NFE) PCI Express cards.
What the SSL Inspector does is simple; the appliance sits inline, taking in and examining all of the traffic on the network looking for SSL handshakes. No matter where in the traffic flow they appear, depending on the SSL Inspection policy, the SSL Inspector can decrypt the SSL flows and pass the plaintext on to whatever security device is being used on the network. It’s important to note that port doesn’t matter, while SSL typically defaults to port 443, it can arrive on any port, and that wouldn’t make a difference to SSL Inspector. This is a critical feature because many SSL applications do not use port 443 and certainly anyone trying to avoid detection with SSL would use a non-standard port number.
The meeting started with a few basic facts about SSL, and some data from Netcraft. One tidbit of info from Netcraft was that the growth of SSL online is about 20,000 new sites a month. Ten years ago, Proch explained, there were maybe ten thousand or so sites using SSL, now there are over a million. This isn’t including internal corporate sites, just straight forward, publically available SSL web servers.
“There are legit reasons to encrypt data. We’re not going to get away from it, more and more we’re seeing that the percentage of encrypted data on a network is rising dramatically,” Proch said during the interview. “A large number of applications are Web-based, SharePoint, SalesForce.com, they all use SSL as default.”
From there we talked about threats to the network that can come from SSL related traffic. What should shock no one is that the same threats that arrive via normal traffic can come over SSL traffic as well. “We’re not talking about breaking SSL. We’re talking about SSL being used as a transport mechanism,” Proch said, adding that SQL Injection attacks can use SSL, botnet C&C centers can use SSL, and so on.
The problem is, while there are hundreds of ways to scan and filter traffic on a network, protecting it from attack, most of the common means are lacking something.
“That’s the key thing. A lot of the exploits that we’re talking about are not new… [they’ve been] in existence or evolving for the past three to five years. All that’s happening now is [that the criminals] are retreading them,” Siket said. “They’re saying we’re going to embed them inside SSL.”
Siket pointed out the logic behind this stems from the fact that all the devices deployed today in a typical network, be it IDS, IPS, UTM, and Firewall, are all configured to ignore SSL. That’s because they’re all applications running on a standard host, a standard server, but these things are not performance optimized and do not support the ability to look into encrypted communications.
“These networks are evolving from 1Gbps, multi-gig, to 10Gbps both at the perimeter and the datacenter, and anything you can do to offload those security appliances from unnecessary traffic benefits performance. A good example of a non-threat that appliances can safely ignore is the payload of VoIP, because there’s no threat in theory embedded in that type of traffic,” he added.
The market for security devices isn’t lacking coverage. While there’s a very fragmented industry, Proch said, many companies with a lot of intellectual property spend a good deal of time doing security analysis. Yet, all these analysis vendors have one thing in common, “…the lack of the ability to look into SSL traffic.”
“I’ve talked to security architects [up to] CSOs,” Proch said, “I’ve actually found it shocking to find out that these guys spend how many thousands of dollars on their security infrastructure, and they don’t even know that their existing devices can’t look into SSL.”
It isn’t a big secret that packet inspection isn’t the number one security purchase in the enterprise. However, most assume that once they have a packet inspection solution in place that’s all they need to provide complete coverage.
So what is SSL Inspector exactly? How is what it does any different from other proxy offerings on the market, was the question asked. They explained that it’s different from a traditional proxy because, while SSL Inspector sits inline, you don’t need to alter browser settings or other client settings like you would expect, the device is completely transparent and examines both inbound and outbound SSL traffic.
The SSL inspection solutions on the market, for example those from Breach Networks or Secure Computing’s SSL Scanner (Secure Computing was bought by McAfee earlier this year), typically only work on inbound SSL by using the keys they have stored internally, which the customer assigns, to decrypt the data that passes through them. The problem, as mentioned earlier, is that usually they stick to port 443 to do this. SSL traffic on other ports is often missed.
SSL Inspector can do that as well, both Proch and Siket said. Inbound SSL inspection to protect your SSL infrastructure is actually simple to do, as you have control of the private keys internally, so decrypting SSL and passing it on to a DLP product, IPS, or IDS will pose no problem. However, you don’t control the keys on an external SSL enabled web-servers, such as SalesForce.com, or Google’s Gmail. So how do you decrypt that SSL data?
Netronome calls the process certificate re-signing. What happens is, once an SSL connection is established, the certificate comes in, and SSL Inspector will intercept it. This creates two SSL sessions, one from the client to SSL Inspector, and one from SSL Inspector to the destination server. SSL Inspector will act as a Certificate Authority of sorts, re-signing the certificate from the destination server and passing it on to the client. Since the client trusts the SSL Inspector as a signing authority, the data that comes after is still secured, but can be read by SSL Inspector and passed on in clear text to the security device of choice.
That’s not all it can do, while the bulk of SSL Inspector deals with decrypting traffic and passing it on to the existing network security devices, it will log events and other data. The overall goal is to control SSL as well as inspect it.
Since most solutions of this type will cause bottlenecks, SSL Inspector has a 4Gbps accelerator card built in. The offering from Netronome is scalable, with baseline support for decryption and inspection of 1Gbps of data regardless of cipher suite, 2,900 SSL setups per second and inspection of 50,000 simultaneous SSL connections.
We walked away from the meeting impressed. While packet inspection, down to a granular level of SSL alone, is something that has existed for a while now, Netronome is doing something unique with hardware they developed first, and application programming that was designed around it.
More information is available online here.