The internet is an essential component of any business. From the use of cloud apps to file sharing and email to cloud platforms like AWS and Azure, most data at some point will traverse the internet. Much of this data is confidential and sensitive. To protect this data in transport across the internet, browsers and cloud apps use encryption. As you connect to websites, an encrypted connection between your browser and the website (cloud application) will be established.
While this encryption prevents prying eyes from viewing your sensitive data, it is important to mitigate risk within this traffic. Advanced threats and malware are regularly delivered within encrypted traffic. This is where SSL decryption comes in. SSL decryption enables organizations to break open encrypted traffic and inspect its contents. The traffic is then re-encrypted and sent on its way. But inspecting encrypted traffic is nontrivial and it requires a proxy architecture.
TSecure Sockets Layer (SSL) and Transport Layer Security (TLS) are both cryptographic protocols that govern the encryption and transmission of data between devices (clients) and destination sites (servers).
SSL was first developed in 1995 by Netscape and released to the public as version 2.0. In 1999, TLS 1.0 was released and was based upon version 3.0 of SSL. Currently, TLS 1.2 is most commonly used across the industry, and TLS 1.3 is on the horizon.
While SSL and TLS are different versions of the protocol, the industry has generally adopted the term “SSL” to talk about encryption and we will do the same in this description.
In addition to finding malware in encrypted traffic and stopping hackers from sneaking past your security engines, SSL inspection is useful when an enterprise wants to know what its employees are intentionally or accidentally sending outside of the organization. SSL inspection is also needed for compliance to ensure that employees are not putting the organization’s confidential data at risk. A multilayer defense-in-depth strategy that fully supports SSL inspection is essential to ensure an enterprise is secure.
Encrypted traffic accounts for most traffic, but many organizations only inspect some of their encrypted traffic, allowing traffic from CDNs and certain “trusted” sites to go uninspected. But that can be risky because webpages are not static. They are served up dynamically with personalized content that may consist of hundreds of objects obtained from multiple sources. Each object poses a potential threat and should be considered untrusted, regardless of source.
At the same time, malware authors are using encryption to hide their exploits. It’s become easy (and cheap!) to obtain a valid SSL certificate and Zscaler researchers have found that more than 50 percent of malware detected is hiding in encrypted traffic. If you allow encrypted traffic to go uninspected, you are blind to a rising number of potential threats.
So why would anyone allow encrypted traffic to bypass inspection engines? The answer is simple: it takes a lot of compute cycles to decrypt, inspect, and re-encrypt SSL traffic, and its performance impact on a company’s infrastructure can be devastating. Companies can’t afford to bring business and workflows to a grinding halt, so they have no choice but to bypass inspection by appliances that can’t keep up with processing demands or the volume.
The common ways to inspect SSL traffic and their key considerations are described in the table below.
|Method of SSL inspection||TAP mode||Next-Gen Firewall (NGFW)||Proxy|
|How it works||A simple hardware device copies all network traffic for offline analysis, including SSL inspection.||Network connections stream through NGFW appliance with only packet-level visibility, which limits detection of threats.||Two separate connections between client and server, with full inspection across network flow and session.|
|Impact of SSL inspection||Hardware TAP requires expensive hardware (e.g., 10G network TAPs) to ensure all traffic is copied at full line rate without any data loss.||Can only see a small portion of malware, allowing malware to be delivered in segmented pieces. Needs additional proxy function (bolt-on). Typically, experience performance losses when additional functionality (e.g., threat prevention) is enabled.||Allows an entire object to be reassembled and scanned. Allows for scanning by additional threat detection engines like sandbox and DLP.|
|Impact on these methods once TLS 1.3 is in use||Retrospectively inspecting SSL will no longer work due to “perfect forward secrecy,” that requires new keys for every ssl session and is mandated by tls1.3.||Adds to performance loss. Appliance refresh is required to achieve the original claimed performance due to the higher performance and scale requirements of new TLS 1.3 ciphers.||Appliance refresh required to meet the performance and scale needs of new TLS 1.3.|
While SSL decryption can drastically help improve security hygiene, organizations must be aware of the ramifications. Organizations often choose not to decrypt certain traffic, such as traffic containing medical or financial data, so they need to set up filters and policies help to ensure that these types of connections remain private.
Regardless, decrypting SSL traffic is an important aspect of an organization's security, and most companies should be inspecting as much of their SSL traffic as they can, in order to reduce risk and keep their users and data safe.
If you want to learn how to inspect all your SSL traffic without costly appliances and without limitations, see how Zscaler’s SSL Decryption can help.
To learn more about SSL Decryption, check out these resources: