Security
Encrypted traffic is becoming increasingly prevalent on corporate networks. By some estimates, over half of the traffic on the Internet will be encrypted by the end of 2015.This poses a problem to organizations who value the security and integrity of their intellectual property and how their employees use the Internet. Because of limitations of many of today’s network devices, this traffic often goes uninspected resulting in the risk of data loss as well as other breaches of security.
First, let us take a look at what SSL really is. While the abbreviation refers to “Secure Sockets Layer”, increasingly it actually refers to its successor. Transport Layer Security (TLS) is the latest in cryptographic protocols that attempt to protect web traffic from being seen by prying eyes. Both are still widely used; they are in fact being used increasingly so because of greater public awareness of Internet surveillance.
Encryption is the process of encoding messages so that only the intended recipient can view them. While it is theoretically possible to decrypt, or decode data, in practice it can take a prohibitive amount of time and CPU resources to do so. Even today’s fastest supercomputers can take a great many years to break encryption via brute force. In fact, it could take far longer than any “would-be” hacker or security analyst would be alive.
With regard to web traffic, as more people rely on encryption it becomes increasingly difficult for organizations to know what data is being sent and received on their networks. This is where the ability to inspect encrypted traffic comes in play. By definition, there is no way to tell what data is being transmitted if the data is encrypted. This is where the ability for organizations to decrypt and inspect encrypted web traffic comes in to play; however, this cannot be done without first having the key to unlock the encryption.
First let us get a general understanding of how encryption works. Most modern methods of network data encryption rely on certificates. A certificate is a type of data that verifies that the entity sending data is who they say they are. It is literally meant to ‘certify’ that both parties are who they say they are. Both SSL and TLS rely on what is known as X.509[4] certificates as part of a Public Key Infrastructure (PKI) in order to give assurance that both the sender and the receiver are known entities who are allowed to engage in encrypted communications.
Most certificates used on the Internet are signed by a Certificate Authority (CA). This helps ensure that that the certificate is valid, and in theory helps maintain a level of trust between the server and the client workstation. When a client first makes a connection to a server, the server presents its certificate. If it is unsigned and thus not automatically trusted by the client, one sees the familiar error indicating that the certificate is not verifiable:
This is key to the topic because inspecting encrypted communications on the corporate network requires what is known as a ‘Man in the Middle (MiM)’ process. Originally the purview of bad actors, a MiM is exactly what it sounds like. One party wants to send a message to another but, as it is handed off between them, another party reads it before passing it along to the intended recipient. As we have already noted, if certificates are not correct the client will see an error. This is intended to alert them to the fact that the encrypted traffic may not be secure.
In order to decrypt web traffic without altering the user, a new certificate needs to be installed on the workstations using the network. The decryption solution thus talks to both the remote server and the client workstation seamlessly without alerting either party.
To this end, modern security solutions offer the ability to decrypt what would normally be encrypted communications between a client workstation and the remote web server. In order to do this in a seamless fashion, the solutions require that the organization deploys its own certificate to the client workstations. This ensures that the client does not see an error when it connects to the remote host.
The actual process of decrypting and inspecting the contents of SSL/TLS is computationally expensive to do with minimal added latency. To this end, there are a growing number of dedicated solutions to provide this service. While many existing firewall solutions can provide this function, unless they are appropriately sized for the task, there can be performance issues. Best practices dictate that a dedicated solution be put into place. The SSL decryption solution either inspects the data itself or hands it off to another solution for inspection.
Employees are increasingly using encrypted web communications for personal email, web browsing, and other tasks. The intent of these inspection solutions in this case is not nefarious. In order to protect from data loss, violation of intellectual properly or inappropriate use of an organization’s network assets, it is entirely appropriate to inspect encrypted traffic. Most solutions allow exceptions to be built to exclude privacy sensitive data such as banking and healthcare websites. While this is a matter for legal counsel to decide, it affords the enterprise the ability to inspect network traffic and provides an important link in the chain of growing security concerns that we all have to deal with.
Exploring the available options for the inspection of encrypted traffic on an organization’s network is increasingly vital and is becoming considered as a best practice. It is crucial to protect data in motion and that cannot be done if that data cannot be inspected.
