In the dynamic and evolving landscape of cloud-based workload traffic, Secure Sockets Layer (SSL) encryption is a critical pillar as it comprises a staggering 90% of all internet traffic, and an even higher number (96%) of all workload egress traffic. While SSL encryption safeguards data transfer, it also provides an ideal channel for malicious actors to export data without detection by security devices. This has led to a growing concern and need for SSL inspection for egress traffic.

The security and performance challenge

SSL inspection often relies on customized compute infrastructure to ensure consistent traffic performance. This is because hardware offloading components are necessary for decrypting and re-encrypting SSL sessions to enable deeper levels of inspection. Cloud providers offer FPGA versions that can be used for hardware offloading required for SSL decryption/encryption. However, these FPGA-based instances are expensive (around 5 times the cost of similar non-FPGA instances) and may demonstrate unpredictable performance for high throughput inspection. On the other hand, security appliances like virtual Next Generation Firewalls (NGFWs) using standard instance types experience a significant drop in performance when SSL inspection is enabled, with performance degradation of up to 60%.

Modern cloud-native applications are designed in a modular fashion using microservices architecture. These applications take advantage of the SAAS solutions available for various components such as analytics, logging, workflows, authentication, software updates, LLM models, and more. These services are offered by SAAS platforms like Dynatrace, Datadog, ServiceNow, Okta, OpenAI, and others. Moreover, software updates from open-source repositories such as Python, Java, Linux, FreeBSD, and Ubuntu are crucial for patching vulnerabilities and keeping applications up to date. Consequently, modern cloud-native applications generate a significant amount of egress traffic that is destined for diverse destinations. To ensure secure communication for these applications, it is essential to perform a thorough and comprehensive inspection of outbound traffic that necessitates SSL inspection.

Image 1: Workload egress traffic destined for diverse destinations

Public clouds, being distributed globally, have made it possible for enterprises to deploy applications in closer proximity to their users. It is common for applications to be deployed in multiple regions to cater to nearby users. Furthermore, each business unit may have its own account or subscription for the purpose of cost allocation.

As a result, network and security teams are now faced with the challenge of managing and rotating SSL certificates for security appliances across multiple regions, accounts, and subscriptions. This responsibility of certificate management and rotation becomes even more burdensome as the number of virtual NGFW appliances continues to grow.

To add further complexity, not all applications are compatible with SSL inspection. Applications that have certificate pinning enabled or legacy applications that cannot trust an intermediate certificate may terminate their connections when SSL inspection is enabled. Additionally, certain application vendors like Microsoft and Zoom do not recommend decrypting egress traffic for specific applications due to network connectivity principles or latency sensitivity. This necessitates the need for more precise controls to inspect SSL traffic for desired applications.

When enabling SSL inspection, security operations (secops) teams need to enforce foundational SSL encryption parameters. These parameters include minimum encryption levels, preferred encryption methods, desired encryption strength, and minimum protocol version.

Customers in highly regulated industries are obligated to adhere to stringent security and privacy requirements. This often involves demonstrating the use of the most secure SSL parameters while inspecting application traffic. Therefore, they require a method to retrieve SSL inspection parameters, including encryption levels, methods, strength, and protocol version information, from the security vendor or device responsible for SSL inspection.

Customers are seeking a solution that can provide SSL inspection with consistent performance, is easy to use, and supports versatile deployments

The Power of High-Performance SSL Inspection

To tackle this crucial security challenge, Zscaler provides high-performance SSL inspection for application egress traffic at cloud scale, ensuring no drop in performance. Zscaler's solution is compatible with cloud native components like AWS Gateway Load Balancer (GWLB), Azure Internal Load Balancer, and GCP internal load balancer. It can scale up to handle the maximum throughput supported by these cloud native components while maintaining optimal performance.

The Zscaler Zero Trust Exchange platform utilizes specialized infrastructure across its 150+ data centers to perform SSL inspection at scale for globally-distributed customer traffic. For customers using Zscaler Workload Communications to enable zero trust for cloud workload traffic, Zscaler provides a cloud connector. This cloud connector is a virtual machine (VM) that acts as a forwarding gateway to Zscaler's Zero Trust Exchange. These VMs can be scaled vertically or horizontally to securely tunnel workload traffic from public clouds to Zero Trust Exchange for SSL inspection. The Zero Trust Exchange processes and protects over 350 billion transactions per day, with 90% of these transactions being SSL encrypted.

Image 2: SSL inspection performed at scale in Zscaler’s Zero Trust Exchange

Zscaler’s approach to SSL inspection is based on five key pillars that maximize security and ensure cloud-scale performance:

Image 3: 5 pillars of SSL inspection

Pillar 1: The right architecture for scale

Your SSL inspection solution must be able to scale and decrypt 100% of traffic without any impact on throughput or latency. There can be no compromises in this area. High throughput and low latency are crucial for maintaining consistent application performance and enabling SSL inspection for all network traffic. Inspecting all network traffic is essential to avoid any blind spots in your cloud egress protection.

This is where capacity-constrained legacy NGFW appliance vendors suffer the most and compromise either on coverage or throughput. To illustrate their struggle, it’s not uncommon to see legacy NGFW vendors publish deployment best practices for decrypting only “high risk” URL categories, while trusting the others:

These constraints put customers in a precarious scenario in which risk can go unchecked, unmanaged, and unmitigated.

The best way to achieve high scale is through a multitenant and purpose-built solution with custom-built SSL-accelerated hardware.

Pillar 2: Easy-to-use

In an ideal world, customers would just flip an SSL switch and everything would automatically work. In reality, risks due to various compliance regulations and incompatible applications need to be managed for a successful rollout.

The top operational feature is a robust, rule-based SSL inspection that allows you to pick and choose which traffic gets inspected and which traffic gets exempted, based on traffic source and destination. The following is a great example of how Zscaler includes extensive options for configuring rules:

Image 4: Multiple filters/criteria enable flexible and granular SSL inspection policies

The Zscaler SSL rule engine supports over a dozen criteria, allowing the secops / netops teams to selectively enable SSL inspection for a subset of workload traffic. For example:

Managing SSL inspection levels based on varying data privacy regulations
Managing SSL inspection levels based on accounts/subscriptions/projects, VPCs/VNETs/subnets
Managing SSL inspection levels based on user-defined tags and cloud provider attributes
Excluding legacy applications from SSL inspection
Enabling SSL inspection in a staggered manner for a smoother rollout and adoption

For multi-cloud deployments that include AWS, Azure, and Google Cloud regions, network and security teams have the flexibility to enable SSL inspection for:

All clouds and regions
All workloads in a specific cloud, for e.g. AWS
All workloads in a VPC or VNET
Specific workload in a VPC or VNET’s subnet

Image 5: SSL inspection applied at varying application scope

Pillar 3: Secure decryption

When opening up encrypted SSL traffic, it is vital that the security of the end-to-end connection is not sacrificed and that all sensitive cryptographic key material is safely handled according to industry best practices.

Pillar 3a: Optimized cipher suites and TLS version selection

This tends to be overlooked due to the complex nature of cipher suite variants. The SSL inspection solution must guarantee that cipher suite strength is equivalent to, or stronger than what is negotiated without SSL inspection. For example, if a client machine? proposes a perfect forward secret (PFS) cipher suite such as ECDHE_RSA_WITH_AES_256_CBC_SHA384), the SSL proxy needs to prefer it over weaker static RSA ciphers.

The Zscaler design principle aims to make this process as simple and secure as possible. Zscaler chooses the strongest cipher advertised by the workload and always proposes a strength-prioritized list of cipher suites to the server, even if it results in additional cryptographic computation overhead.

The following illustrates this principle through the Zscaler TLS 1.3 acceleration hardware upgrade that was completed in December 2021. Once this was launched, our customers observed, overnight, a major difference in TLS version negotiation both on their client side and server side. This significant upgrade was seamless for our customers across the board. Imagine the substantial operating efforts needed to manually instance types, OS, and drivers on virtual security appliances in order to achieve similar results.

Pillar 3b: Key Material Safeguarding

Zscaler offers two intermediate Certificate Authority (CA) enrollment models: bring-your-own CA and the Zscaler default root/intermediate CA. For the first option, Zscaler acts as a key custodian on behalf of a customer and assumes responsibility to protect it.

While the widespread adoption of perfect forward secrecy (PFS) ciphers has mitigated the risk of passive eavesdropping, an active MITM attack is still possible. Issuing a CA private key is like issuing a key to the kingdom. If a bad actor gets ahold of a private key, they can issue arbitrary forged certificates for trusted domains. In combination with DNS poisoning, the bad actors can launch MITM attacks using certificates that appear trusted to the client.

To mitigate this risk, Zscaler employs a robust array of key material safeguarding techniques - from short-lived keys and revocation endpoints to stringent production access and audit, along with other compensatory management, operational, and technical safeguards. The highlighted CA below (t stands for temp), showcases Zscaler’s short-lived issuing CA that is automatically rotated on a weekly basis, significantly minimizing potential attack windows.

To further advance key protection, even for the most highly regulated and security-stringent organizations, Zscaler recently launched a first-of-its-kind turnkey Cloud HSM (FIPS 140-2 Level 3 validated) solution for safeguarding our customers issuing CA private keys—the industry gold standard for key protection. In the fully integrated solution, the CA private key will reside for its entire lifetime inside the Cloud HSM and be used dynamically to sign domain certificates.

Pillar 4: Design for privacy

Opening up an SSL connection that was supposed to preserve privacy inherently introduces risk to privacy. The right architecture mitigates this risk.

Security and privacy are at the core of the Zscaler architecture. Our fundamental principle is that we should minimize the data sets that are collected and secure them across the whole lifecycle; in-use, in-motion and at-rest.

Don’t just take our word for it, all our information security controls are validated by independent third party assessors against all the leading compliance and data privacy frameworks, including DOD IL5 which is the US Department of Defense highest standard for cloud vendors. Zscaler also undergoes an independent Sensitive Data Handling Assessment that verifies documented encryption controls and client key management, while also validating that any stored key information is unexploitable through an examination of activity logs, core dump files, and database schemas. To learn more visit here

Pillar 5: Visibility

Comprehensive operational visibility is vital for both establishing trust and addressing several key questions:

What is your SSL inspection coverage?
Are there any problems due to incompatible apps?
Are you observing any obsolete TLS versions?
Are you using the most secure ciphers?
What value are we getting from the SSL inspection (i.e. threats, DLP incidents)?

The foundation to address these questions starts from the raw log data. A robust logging plane capable of capturing high-fidelity and context-rich transaction-level logs at scale (not aggregate level that other vendors may resort to due to architectural deficiencies) is imperative. Zscaler’s Nanologs capture 18+ unique TLS log fields for each TLS connection (decrypted, undecrypted, and failed) as seen here:

Once you have the basics in place, answering the operational and value questions is straightforward.

Example 1: Failed client SSL handshake logs proactively surface misbehaving clients:

Conclusion

Zscaler's platform enables scalable SSL inspection, capable of handling the throughput supported by cloud-native egress solutions without sacrificing performance. SSL inspection at scale is a crucial capability to protect workloads and application data, but since the original protocol was not designed to be inspected by a trusted third party, it also introduces risk. Zscaler acknowledges and mitigates these risks through its purpose-built cloud-native security platform following five fundamental principles. Given that over 90% of Internet traffic is now encrypted, and malicious actors that include insider threats have leveraged the privacy provided by SSL to disseminate malware and exfiltrate data, inspecting this traffic at scale becomes critical for preventing compromise and data loss, along with improving survivability in the current threat landscape. While there are risks associated with performing SSL inspection, Zscaler has implemented controls, as outlined in this article, that has made this an acceptable level of risk for over 7,000 global customers.

To find out more, visit our product webpage and watch the webinar.