Remove the SSL Blind Spot with A10 Thunder SSLi
Organizations use encryption to keep sensitive traffic safe and protected. But the bad guys have caught on to that, are now using encrypted traffic to conceal their nefarious doings. This leaves security pros in a tough spot: encrypt traffic and run the risk of bad stuff slipping through the cracks or let traffic flow unencrypted, which is a massive security risk and likely a compliance violation. But those are no longer the only choices. Organizations can implement solutions that decrypt and inspect encrypted traffic.
Here, we look at the power of decryption and why organizations should make it a key part of their security architecture.
Why should I decrypt my outbound traffic?
In short, the bad guys are winning. You are spending more and more on security while getting less and less value. Breaches are still happening. Yahoo, Whole Foods, Equifax, Verizon; do those names sound familiar? They’ve all been in the headlines in 2017 admitting that they’ve had security breaches.
Hiding malicious traffic in SSL is the new frontier – whether for infiltration, exfiltration, or maintaining a foothold with Command and Control (also known as C&C or C2). Since upwards of 70 percent of outbound traffic to the internet is SSL, it’s the easiest way to go unnoticed in today’s world.
There’s an adage that goes something like this: “The best place to hide a tree is in the forest.” If malware’s SSL communication is the tree, are you less likely to spot it among all of the other trees (your legitimate SSL traffic), or if the proverbial tree was in a field by itself?
Wait a minute! Can’t my Next-Generation Firewall do this?
Most likely! But it comes at a cost. Most of the Next-Generation Firewalls (NGFWs) out there perform SSL decryption on the same general-purpose CPU (think Intel or AMD processor) as the rest of the data plane traffic. That means your firewall’s processing capabilities are significantly reduced because it’s trying to handle all of the resource-intensive SSL decryption at the same time as it’s trying to process the rules and policies you’ve configured.
What about your other security devices? Web Content Filter? IDS/IPS? DLP? Malware and threat prevention? Forensic tools that hang off a network tap? It’s great if your NGFW is decrypting traffic for itself, but it’s not sharing with the rest of the class. After decrypting the traffic (inefficiently in a general-purpose CPU), they have to re-encrypt the traffic before sending it on down the line. Assuming your other security devices can decrypt traffic (not all can), you’re stuck doing the same “decrypt, analyze, re-encrypt” dance at every security device in the line.
A10 Thunder SSLi to the Rescue!
“That’s great,” you may be thinking, “but how does A10 help us out here?” With A10 Thunder SSLi (SSL Insight) we leverage hardware ASICs, which are much faster at SSL decryption/re-encryption, to offload that responsibility from your security devices. This helps you truly eliminate the SSL blind spot by allowing ALL of your security devices to benefit from centralized decryption with hardware ASIC acceleration.
At that point, the data plane CPUs on your security devices are free to do what you purchased them for – keep you secure from the bad guys.
What Makes SSLi Different?
SSLi is designed from the ground up to be as flexible as possible, because no two networks are the same. Some of SSL’s key features include:
- Flexible Deployment Model – Whether itâ’s Layer 2, Layer 3, or Explicit Proxy, we can accommodate nearly any network design.
- Vendor Agnostic – When it boils down to it, we don’t really care what you put in the middle of the SSL ‘sandwich.’ As long as your security device knows how to take in the decrypted traffic on one side, analyze it, and spit it out the other side, it will work with our design.
- Full Proxy Architecture – From a network perspective, the TCP session on the client side (facing the client), and the server side (facing the server on the Internet) are decoupled. This gives us the flexibility to have complete control over both sides of the connection from Layer 3 on up, and even do things like having lesser SSL ciphers on the inside of the network for speed, but stronger SSL ciphers on the outside Internet where it’s really important. Learn more about full proxy in this video.
- HSM Support – For high-security environments like government organizations, there may be requirements for the SSL decryption keys to be protected with an HSM, or Hardware Security Module. This operates like a black box to protect the SSL keys from being leaked even if something crazy happens, like the device is physically stolen from the data center. For our devices with HSM support, we can use anywhere from one to four integrated HSMs in a single device, and we actually wrote our own ‘œoverlay driver’ to ‘load balance’ across multiple HSMs for performance purposes.
- Dynamic Port Inspection – We also support what we call ‘Dynamic Port Inspection,’ which allows us to decrypt SSL-wrapped traffic on any port, not just port 443 where most of it happens. Under the covers, this works by sniffing the first few bytes of every new connection, looking for the tell-tale signs of an SSL/TLS handshake. If we see one, we’ll step in and intercept the traffic; if not, we’ll allow the traffic to pass just as it normally would.
- ICAP Support and More – We also support the ICAP protocol for talking to DLP systems or web-content filters, STARTTLS and even SSH Intercept.
At this point you’re probably thinking, “It’s great that you can decrypt all of my traffic, but what about traffic that I do not want decrypted?”
Through a partnership with Webroot, A10 Thunder devices have access to Webroot’s URL intelligence database for URL categorization data. Every site on the Internet carries one of nearly 90 different categories. You may be familiar with URL categorization in your content filters, where you can set a policy to allow or deny users on your network to access sites which fall into a particular category. However, we do not use the URL categorization data to allow or deny access, but to choose which traffic should or should not be decrypted.
For instance, if your company has an acceptable usage policy that says users can engage in casual web browsing during downtime as long as it doesn’t affect their normal duties, there is a high likelihood that a user may access their online banking or a healthcare site using the corporate network. That’s the type of traffic we do not want to decrypt.
In those scenarios, we can set a policy to allow traffic which falls into those “sensitive” categories to be excluded from decryption. The traffic still flows through the devices in your security stack, but it remains encrypted. You can also maintain a manual list of either DNS hostnames or source/destination IP addresses to be excluded from decryption.
Putting It All Together
The next question that usually comes up is, “That all sounds great, but how hard is this to set up?”
The answer is that it’s actually surprisingly easily. In most of the deployments I’ve done, about 80 percent of the effort is ensuring that the traffic flow is correct. Since this is a stateful device, we need to ensure that if traffic goes out, it comes back the same way, and we must avoid any asynchronous routing.
For common deployment methods like we talked about earlier, we have what we call an ACT, or App-Centric Template. This is like a “next, next, finishâ” wizard that does most of the deployment for you. You specify your incoming/outgoing interfaces, SSL decryption certificate, SSL decryption bypass list, apply the policy and go.
We also have a full REST+JSON API under the covers if you’re like me and into network automation, and are also certified with Cisco ACI.
There you have it. That’s just a short exploration of why you should decrypt and inspect traffic and how SSLi can do the heavy lifting for you, without sapping the performance of the rest of your security stack. Not a bad proposition, right? Now get out there and remove that SSL/TLS blind spot.
I recently sat down with the folks at Packet Pushers for a podcast talking through some of these points. You can tune in here (my appearance starts around 34:30).
Want to learn more about SSLi? Download our data sheet.