The Encryption Paradox
Security experts universally agree that network traffic must be encrypted to be considered secure, and many compliance standards and applications (let alone common sense) require it. However, encryption creates a paradox for network security monitoring.
Encryption protects the data in an organization’s network traffic by encoding information, allowing only those with a “key” to decode it. But by doing this, it also locks out security operations from effectively monitoring said network traffic.
The standard method of encrypting web traffic—SSL* —encrypts traffic directly between a client and server pair, protecting information as it crosses the Internet.
As mentioned earlier, this presents any network security analyst, device, or third party that tries to see into these conversations with a major problem. The problem is they will only find encrypted, practically useless, data.
Fortunately, there’s a relatively easy way to navigate this paradox: using an SSL Proxy.
How Do You Access Unencrypted Data?
Think like a Hacker
Security professionals trying to protect their own network often adopt hacking techniques to do so, and this is one such case.
When faced with an encrypted SSL channel, a creative solution used by malicious actors is pretending to be both sides of the conversation. The client will think the attacker is the server, while the server thinks the attacker is the client. This is known as a “man-in-the-middle” attack, and it requires the attacker to be in a position where they can intercept the client’s traffic.
Once the man-in-the-middle tactic has been successfully executed, the attacker can relay information between the two while they believe they are communicating directly. The attacker will see everything in the clear, even as both the client and server think that they are secure.
Setting Up a SSL Proxy
By emulating a man-in-the-middle attack in a secure and controlled way, SSL proxies provide security teams with the same capability—access to the unencrypted traffic.
These network appliances act as an intermediary between all clients in the network and the Internet; therefore, all outgoing SSL traffic from internal clients will go through the SSL proxy. This means that you can see, in clear text, both sides of the conversation between client and server.
There is one catch: To avoid falling for a man-in-the-middle attack, most modern operating systems know when they are being “proxied” using digital certificates.
In general, this is a good thing. But it does introduce the trickiest part of setting up a legitimate SSL proxy, installing the proxy’s certificate on every client.
Once the certificate is installed, clients must “trust” the proxy appliance and allow it to act on their behalf. Once the proxy is in-line and the certificates installed, any network security device that needs unencrypted network traffic can tap into the proxy.
LogRhythm NetMon
LogRhythm’s network security appliance, NetMon, and its application-layer rules engine, Deep Packet Analytics, provides visibility into corporate, cloud-based applications, communications to third-party companies and applications, and most importantly, potential attacker communication back to their command and control infrastructure.
With the increasing number of encrypted applications, NetMon and any other network security device will only reach full potential when working in conjunction with an SSL proxy.
Complete Visibility
To achieve complete visibility, LogRhythm NetMon can be integrated with an increasing number of SSL appliances. This allows the advanced capabilities of LogRhythm’s NetMon appliance to work alongside a secure, encrypted network.
For organizations serious about their security, monitoring network traffic with deep packet inspection is vital. As the number of applications, adversaries, and malware using encryption increases, effective monitoring is only possible with an SSL proxy.
*Author’s note: Secure Sockets Layer (SSL) is technically the older version of this technology, and versions with “SSL” in the name are deprecated (i.e., you should not be using SSL 3.0). The version that should be used is Transport Layer Security (TLS) (e.g., use TLS 1.2). However, many people still refer to both TLS and SSL as SSL.