Use SSL Decryption to see what is flowing in to the Data Center

SSL provides benefits to the end user and a potential threat to the data center.

Users who want to access their bank account need to be sure that no one who is reading their password or bank account information. Banks provide that security by using SSL encryption on the authenticating portion of their web site. When the user logins in to https://mybank.bz (Note the “s” in “https.”) no one can read that traffic, because they cannot decrypt it.

Someone working in the IT department of an organization has a much more sophisticated understanding of firewalls and understands that he or she can use VPN or SSH to bypass an organization’s security. For example, if Facebook is blocked at work, the savvy IT engineer can use VPN to connect to their home-based computer and then use that to surf the net free of corporate meddling. Since that traffic is encrypted, the organization has no idea what data is passing back and forth. The user can also can use SSH to create a SOCKs connection to proxy HTTP requests through an encrypted tunnel or connect directly to a server outside the firewall.

The goal of the IT security department is not to spy on employees, rather it is to make sure that they do not accidentally introduce malware into the corporate network or let hackers hijack their machine. Towards this end, it is necessary that the firewall can read encrypted traffic.

Companies like Juniper and Palo Alto Networks have SSL decryption built into their firewall devices, so that their clients can monitor what passes through their firewall. The name “decryption” here is a bit of exaggeration on their part; their scientists have not cracked open the mathematical puzzle that protects all encryption algorithms. Instead they use the rather low-tech, man in the middle approach to read encrypted traffic, inspect it for malware, decrypt it again, and then send it on its way. The sender and receiver have no clue that someone is reading their data.

Here is how that approach works. When a user goes to an SSL-encrypted web site, or when they use SSH, the web or other server issues a session ticket which is a private key (used to decrypt traffic) and public key (used to encrypt traffic). The man-in-middle approach is to hijack these keys and present themselves as the intended recipient. Someone attacked in this manner will not realize that a third party is listening in and even changing messages sent back and forth.

There are various techniques built into Ethernet switches designed to mitigate this threat, but the firewall has a unique vantage point. It is not an Ethernet switch, and it is sitting right there in the middle, i.e., between the sender and receiver.

Because of the increased awareness that someone (hint, hint, the US government) is listening in, Twitter, Google, and other popular web sites have offered the SSL option to encrypt traffic. Some would say this is silly: why put a picture of yourself in your bikini on the internet, where the whole world can see it, and then ask that Facebook encrypt it?

The reason that not all web sites use SSL all of the time is the expense. Doing the mathematics required to encrypt and decrypt traffic is time consuming by design. The company can let the web server do this or add an SSL accelerator to offload some of that work. Either way more hardware is needed.

That said, it is necessary that a company decrypt encrypted traffic, as Orwellian as that may sound, so they can read what is passing through the firewall to make sure no one is taking advantage of that gateway to do harm. They don’t actually “read” anything, instead they inspect packets looking for malware signatures or peer more deeply and look to see if corporate information is going out the door.