Post Content
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
