Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

What's lurking in your network? Find out by decrypting SSL

Brian Heder | Jan. 21, 2013
Organizations have spent vast sums of money on security systems and, when deployed and operated correctly, they play a key role in safeguarding the organization. However, most systems have one critical dependency: The traffic flowing through must be readable. If the traffic is encrypted, many systems are almost completely useless, giving the system owner a false sense of security.

When your browser wants to communicate with an encrypted Web server, the following sequence of events occurs (depicted graphically in Figure 1 for those who like pictures).

Make sense? The key to understanding PKI encryption is the relationship between the public and private keys; the public key is used to encrypt, and the private key is used to decrypt. And since the only entity in the whole world that has access to the private key is the server, anything encrypted by the public key can only be decrypted by the Web server.

Now that we have a basic understanding of PKI, let's get back to the subject at hand. To decrypt traffic so your security tools can examine it, we have to get in the middle of the session. How we do this depends on the function or type of traffic you are trying to decrypt. There are two categories:

Let's take a look at each of these and explore how to decrypt each.

Decrypting inbound traffic

Let's say your company has a website hosted on a Web server in your data center. The website uses SSL, so all traffic to and from the website is encrypted. When a client on the Internet accesses the site using a computer, smartphone or tablet, an end-to-end SSL-encrypted connection is established between the client's browser and the Web server, making the connection completely invisible to your organization's network security tools.

Decrypting this traffic to make it visible to your security tools requires two steps:

The first step is easy, but the second step can be accomplished in several ways (depicted in Figure 2):

Each of the above methods has its strengths and weaknesses, and which is used in a given architecture depends on many factors. However, they all share one key point: Unencrypted data never leaves the device. As a result, end-to-end data encryption is maintained.

Decrypting outbound traffic

With outbound traffic, the vast majority originates from employees browsing the Internet, checking their email, posting on Facebook, etc. This traffic is potentially damaging to your organization in numerous ways: Users may send proprietary company information over web-based email, post confidential data on social network sites, etc. Every user in your organization who accesses an encrypted website is a potential point of entry into your network, or point of exit for confidential information.

Decrypting outbound traffic is a little trickier than decrypting inbound traffic. As we just discussed, when decrypting inbound traffic we load the private key for the server onto the decryption device, giving it the ability to decrypt traffic to or from the server. But we can't load the private key for every single Web server on the Internet onto your security device, so another strategy is necessary.


Previous Page  1  2  3  Next Page 

Sign up for Computerworld eNewsletters.