TLS, SWG, and the New Encrypted World Order: Part 1

As the volume of encrypted traffic surpasses the volume of unencrypted traffic globally— businesses are faced with a dual-edged dilemma.

On one hand, encryption protocols such as TLS act as the valiant knights of the digital realm, fortifying sensitive data and thwarting unauthorized access—ensuring the sanctity of digital communications and transactions.

On the flip side, it can conceal threat actors and malicious content moving through the same channels. For instance, HTTPS is the standard for encrypting and protecting data on the web—yet threat actors are using TLS/SSL to quietly move malware, ransomware, and phishing attacks past defenses.

In fact, 86% of cyberthreats are disguised using encryption, with a 24.3% YoY growth in encrypted threats.

This duality raises the question: is TLS encryption the panacea or the pandora’s box?

Decrypting the traffic jam: Why most businesses get stuck

The widespread adoption of TLS poses an often overlooked but critical challenge—businesses’ limited visibility into encrypted traffic. Organizations lack the ability to decrypt traffic at scale due to multiple factors:

1. Resource crunch

This hurdle applies particularly to businesses relying on appliance-based solutions, either on-premises or in the cloud.

It may be hard to believe, but enabling TLS decryption can lead up to a 10x increase in resource utilization, straining firewalls, IPS, and other traditional appliances meant to inspect SSL traffic.

Consequently, many organizations opt for selective SSL and TLS inspection to ensure optimal resource allocation.

2. Compliance concerns

Secondly, concerns about user privacy and potential regulatory ramifications deter some from fully embracing SSL decryption tools, leaving them exposed to cybersecurity risks.

3. Legacy limitations

Legacy firewalls and proxies may struggle to correctly decrypt or adhere to application protocols nested within SSL/TLS—potentially disrupting or corrupting applications.

This issue is particularly acute in developer-centric environments, where improperly inspected SSL/TLS traffic can easily compromise tools and applications.

In fact, at one point, the situation grew so dire that Microsoft advised against TLS inspection for Office 365 (now Microsoft 365) traffic, aiming to mitigate the inundation of customer support tickets.

What happens when you inspect TLS?

The lack of TLS inspection severely restricts your capacity to analyze network traffic. What you may get are limited insights, such destination domains (which are subject to circumvention by specific technologies), and a rough gauge of traffic volume (accuracy is impeded by the padding and encryption overhead inherent in block ciphers).

Conversely, if you use TLS inspection, you can see more detailed data like metadata, content, and URLs, and leverage this visibility to apply other security controls, such as URL filtering, intrusion prevention systems (IPS), access control, and more.

Evolving encryption standards are exacerbating the problem for firewalls

Let us look at the top three ways in which it is happening:

1. Encrypted Client Hello (ECH)

When ECH is implemented in web browsers, traditional security measures reliant on clear text and name identification become ineffective in discerning destination addresses. Only the destination IP address remains visible, rendering other reliable information inaccessible without comprehensive decryption.

ECH functions as an extension within the client hello message, preserving the clear text outer client hello while concealing the actual client hello with server name identification inside a TLS extension—encrypted via hybrid public key encryption.

While this encryption enhances user privacy for regular internet users, it also presents opportunities for misuse. It can circumvent legitimate enterprise controls, redirecting users to phishing websites or unauthorized destinations, thus eluding enterprise security measures.

Additionally, it facilitates evasion of TLS inspection by masquerading destinations as domains typically associated with trusted locations—creating an evasion channel immune to traditional security scrutiny.

Furthermore, the design of encrypted hello client makes it impossible to detect whether traffic is utilizing encrypted client hello or not.

2. Post-Quantum Key Exchange (PQKE)

PQKE is a recent addition to cryptographic protocols. Its integration into the TLS handshake introduces fragmentation, posing challenges for traditional firewalls that must handle fragmented packets—necessitating additional processing.

It has recently been incorporated into Chrome and Edge browsers, employing a hybrid approach that combines classic and quantum key exchange mechanisms for enhancing security.

However, this hybridization adds over 1 kilobyte of extra data to the client's hello message, which might seem trivial but poses significant issues.

The TLS point hello becomes fragmented, requiring multiple TCP segments, and many firewalls are ill-equipped to process TLS correctly under these conditions, leading to strained resources and compromised TLS inspection.

Despite requests to disable post-quantum key exchange due to these challenges, it remains a necessity in the evolving landscape of cybersecurity. Addressing these issues with patches will inevitably increase the workload for firewall administrators.

3. Post-Quantum Digital Signatures (PQDS)

PQDS though it represents a significant advancement—is a bit further from immediate implementation—but can pose substantial challenges for firewalls and web proxies. Currently, there lacks a clear consensus on the future utilization of PQDS, but NIST is standardizing three proposals.

One prominent challenge is their sheer size; while an RSA 2048 signature is merely 256 bytes—PQDS can extend into kilobytes.

As a result, they augment the size of every X.509 certificate, which is typically presented in chains during TLS handshakes, thereby inflating the overall size of digital signatures. This exacerbates fragmentation issues in firewalls and poses resource constraints on any appliance-based decryption—particularly once PQDS is implemented.

Additionally, PQDS may introduce performance implications, as the signing and verification processes become significantly more complex and time-consuming compared to traditional algorithms, potentially slowing down operations by dozens or even hundreds of times.

To be continued…

In the next part of this blog series, we will delve deeper into strategies for overcoming these obstacles and explore how Zscaler offers innovative solutions to navigate the evolving landscape of encrypted traffic management.

Stay tuned for insights on how to address these challenges effectively while ensuring robust data protection in an increasingly encrypted digital world.

Meanwhile, if you want to learn how Zscaler delivers industry-leading TLS/ SSL decryption and does so without burning a hole in your pocket or compromising on functionalities—read the reference guide here.

Do you have a specific requirement and want to consult with our experts? Click here.