What Is Encrypted Traffic?

The vast majority of Internet traffic is encrypted, largely using TLS to ensure data confidentiality, integrity, and authenticity. Transport Layer Security (TLS) is a network protocol that wraps other protocols in a layer of encryption, and is the difference between HTTP and HTTPS for web traffic. Encryption protects against eavesdropping but doesn’t guarantee that the encrypted traffic is safe.

While TLS may be best known for its data encryption, it also offers protection for data integrity and authenticity. By default, HTTPS authenticates the identity of the server using a digital certificate, and mutual TLS (mTLS) does the same for the client as well.

Key Highlights

• Encrypted traffic is network communication protected in transit, most commonly with TLS.
• Encryption improves confidentiality and integrity, and it is now the default for most web and app traffic.
• Encrypted payloads reduce what many network security tools can directly observe and enforce.
• Organizations manage encrypted traffic using a mix of policy, selective decryption-based inspection, and non-decryption visibility methods.
• Modern protocols and privacy features, including TLS 1.3 behaviors, QUIC, HTTP/3, and ECH, can change what metadata remains observable.
• Teams usually have to trade off security visibility against application reliability, user privacy, and data minimization requirements.

What Does “Encrypted” Mean in Network Traffic?

Encrypted traffic refers to the encryption of data in transit, often using TLS (a replacement for insecure SSL). Data can also be encrypted at rest using AES and similar algorithms. Data encryption in transit converts network traffic into unreadable ciphertext before the sender transmits it over the network. The recipient has the decryption key and can use it to restore the original data.

What Are Common Examples of Encrypted Traffic?

Most Internet traffic is now encrypted since encryption helps to ensure authenticity and integrity of the transmitted data, as well as protecting it against eavesdropping. For example, most modern web traffic – including web browsing, SaaS application traffic, API calls, and mobile app traffic – uses the encrypted HTTPS protocol, which wraps HTTP in TLS.

Other network protocols are also encrypted, either by design or through the use of TLS as well. Examples include:

• VPN traffic (site-to-site and remote user)
• Secure email transport and retrieval (SMTPS, IMAPS, POP3S)
• Admin and file transfer protocols (SSH, SFTP)
• Modern voice and video media streams (SRTP), plus conferencing app traffic

Why Encrypted Traffic Has Become the Default

Most network protocols that make up the modern internet (HTTP, DNS, etc.) aren’t secure by default, lacking data encryption, authentication, and integrity protection. Today, the use of encrypted protocols has become the default for several reasons, including:

• Data privacy
• Enhanced security
• Regulatory compliance
• Web browser and platform defaults

Why Encrypted Traffic Matters for Security and Operations

Traffic encryption using TLS has several benefits, protecting data confidentiality, integrity, and authenticity. This is important because, without it, network traffic could be vulnerable to eavesdropping and modification en route to its destination. At the same time, traffic encryption creates security challenges as well since, like attackers, security tools can’t read the contents of encrypted traffic by default. This is problematic because malware, PII, and vulnerability exploits may be hidden within encrypted traffic.

Decrypting network traffic requires either access to endpoints or breaking the TLS connection and performing computationally expensive TLS decryption within network security tools. As a result, security tools often use metadata, performance signals, and endpoint telemetry to identify potential threats.

What Can Security Teams Still See When Traffic Is Encrypted?

While TLS encrypts the content of a network packet, some information must remain decrypted to allow the packet to reach its destination. Some of the metadata that security teams can still see in encrypted traffic include:

• Source and destination IP addresses
• Source and destination ports.
• Timing, volume, and flow characteristics.
• Some handshake and certificate details (changing with ECH and privacy efforts)

However, the utility of this information also depends on how the traffic is encrypted. If an IPsec VPN is used instead of TLS for encryption, IP addresses and ports will point to the VPN endpoints, not the final destinations of the network traffic.

How Organizations Manage Encrypted Traffic in Enterprise Environments

Organizations can take two different approaches to managing the security risks of encrypted traffic:

1. Decrypt the traffic and inspect the contents
2. Examine unencrypted metadata to infer risk without decryption

Often, organizations use a combination of the two techniques. For example, they may default to examining metadata and only perform decryption for traffic that is identified as potentially risky.

Approach 1: Decryption-Based Inspection

The first potential approach is to inspect encrypted traffic, also known as TLS or SSL inspection. Under this model, a security appliance decrypts the traffic at an inspection point, evaluates it, and then re-encrypts it for delivery. This allows the organization to enforce policies, detect threats, scan for malware, and implement content controls that require visibility into the payload.

However, this approach also introduces risk since it requires breaking the encrypted TLS connection, often by creating two separate encrypted connections, one from the client to the security appliance and the other from the appliance to the server. Decryption introduces privacy risks, can harm performance, and adds complexity that might break applications.

How Does Decryption-Based Inspection Work?

Decryption-based inspection works by breaking the encrypted TLS session into two separate sessions with a decryption point in the middle. This includes the following steps:

1. Client initiates a TLS session.
2. Inspection point intercepts and terminates the session.
3. Inspection point establishes a separate TLS session to the destination.
4. Content is decrypted and inspected according to policy.
5. Traffic is re-encrypted and forwarded.

What Role Do Certificates and Trust Stores Play?

For the inspection point to create a session with the client, the client needs to accept that its digital certificate is a valid certificate for the target site. This is often implemented as a wildcard digital certificate that applies to any site that the client might visit.

This approach requires significant trust in the enterprise and its security since the client can no longer validate the real digital certificate provided by the target site. As a result, this digital certificate is a common source of misconfigurations, security risks, and outages.

What Gets Inspected After Decryption?

After traffic is decrypted at the inspection point, the security appliance has full access to the packet’s payload. This allows it to implement various security functions, such as:

• URL filtering
• Malware scanning
• File type controls
• Data loss prevention
• Identification of threat indicators in content

Approach 2: Non-Decryption Visibility

Decryption isn’t always an option (or the best option). An alternative is for security tools to infer the risk associated with a connection using metadata, flow behavior, endpoint telemetry, and other signals without decrypting payload content. Signals used for this analysis include:

• Flow-based analytics
• Behavioral anomalies
• Known-bad IP and domain intelligence
• Certificate and handshake anomalies (where visible)
• TLS fingerprinting and client hello characteristics (where visible)
• SNI and ALPN metadata when not protected by ECH
• Certificate reputation and anomalies (issuer patterns, validity windows, suspicious self-signed chains)
• Destination classification plus historical baselines for byte ratios, burst patterns, and session durations

This approach has some benefits since it eliminates the overhead and privacy risks associated with traffic decryption. However, they may miss threats that are only visible within the payload of the network traffic. Organizations can also use AI-based encrypted traffic analysis to enhance the effectiveness of this technique.

What Breaks in the Real World When Managing Encrypted Traffic?

Decrypting encrypted traffic for analysis can introduce potential issues for the business. To avoid app breakages, organizations should implement certain policies and technical controls.

Certificate Pinning and Strict Certificate Validation

Enterprise traffic decryption typically requires replacing the server’s digital certificate with an enterprise inspection certificate. This may be problematic if an application implements certificate pinning or strict certificate validation, where it only accepts a particular digital certificate for a target website.

If this is the case, applications may fail, experience authentication loops, or fail to update. Possible solutions include bypassing inspection for these apps, using endpoint security controls to inspect traffic before/after encryption, or reviewing vendor guidance for solutions.

Mutual TLS (mTLS) and Client Certificate Authentication

Mutual TLS (mTLS) authenticates the client as well as the server using digital certificates. This can cause interception to fail if the inspection point can’t correctly pass through, validate, or re-originate client certificate authentication. 

Possible results include API failures, repeated authentication prompts, and sudden “unauthorized” errors after enabling inspection. To mitigate this, organizations may bypass inspection for specific mTLS destinations, use endpoint-aware controls, or configure explicit support for client certificate passthrough, where available.

Unsupported Protocols, Ciphers, and Edge Cases

Inspection tools may not support every protocol or negotiation pattern used by an application and/or server. If this is the case, the inspection point may fail to negotiate one or both of the encrypted connections it maintains with the client and server.

Symptoms of this issue include connection failures, intermittent timeouts, and partial page loads. Potential mitigations include updating the inspection point to include missing protocols or rescope inspection policies to exclude that application.

HTTP/3, QUIC, TLS 1.3 Behaviors, and ECH

Modern protocols, such as HTTP/3, QUIC, and ECH, change how interception works or the unencrypted metadata used to analyze encrypted traffic. For example, Encrypted Client Hello (ECH) encrypts more of the TLS handshake, reducing the available unencrypted data.

As a result, the organization may need updated tooling or different approaches for network flows using these protocols. Some organizations temporarily block or downgrade QUIC/HTTP/3 (forcing HTTP/2 over TLS) to preserve inspection and consistent policy enforcement, then re-enable as tooling and policies mature.

Privacy Boundaries and Regulated Categories

In some cases, inspection should not be performed even if technically possible. For example, many organizations will avoid decrypting traffic to healthcare portals, banking, personal email, and employee self-service systems to maintain compliance with data privacy laws. To avoid accessing sensitive personal data, traffic decryption programs should be under strict governance, auditable, and decrypt as little sensitive and private data as possible.

How Can Performance Degrade with Multiple Inspection Hops?

Decryption is computationally expensive and can introduce latency into network connections. If multiple security appliances or proxies independently decrypt and reencrypt the data, this can increase network latency and potential failures, causing slow page loads, timeouts, and inconsistent performance.

What Does “Single-Pass” or “Single-Scan” Inspection Mean?

Single-pass or single-scan inspection performs a single round of traffic decryption/reencryption for security inspection. Multiple security functions may access the decrypted data, offering the same level of security while reducing the number of redundant cryptographic steps and the associated network latency.

Best Practices for Handling Encrypted Traffic Without Breaking the Business

Encrypted traffic inspection may be necessary for security, but it can also cause harm to the business if implemented incorrectly. Some best practices include:

• Starting with clear goals and use cases.
• Defining decrypt versus bypassing categories explicitly.
• Piloting with non-critical groups and known app sets.
• Monitoring performance, error rates, and user impact.
• Building an exception process for pinned apps and high-risk breakage cases.
• Minimizing logging and retention of decrypted content. 
• Using least-collection principles.

How Should Teams Decide What to Decrypt Versus Bypass?

Traffic decryption is not always necessary, and organizations need to decide whether traffic requires decryption. Some factors to consider include:

• Business criticality
• Data sensitivity and privacy risk
• Threat exposure and abuse likelihood
• Known app behaviors like pinning
• Operational tolerance for outages

FAQ about Encrypted Traffic

What is encrypted traffic in plain terms?

Encrypted traffic uses cryptography to protect network traffic against eavesdropping and malicious modification. TLS is the most common protocol for traffic encryption and is the difference between HTTP and HTTPS web traffic. While encryption protects data integrity, confidentiality, and authenticity, it doesn’t guarantee that the encrypted data is benign.

Is encrypted traffic the same as HTTPS?

HTTPS is a common form of encrypted traffic, using TLS to protect HTTP traffic. However, there are other forms of encrypted traffic as well, including VPNs and other network protocols protected by TLS.

What is TLS, and why do people still say SSL?

TLS is the successor of SSL, which is insecure. People may still say SSL or SSL/TLS while referring to TLS out of habit or acknowledgement of this legacy.

Why can encryption create security blind spots?

Encryption can create security blind spots since security tools can’t read encrypted data to look for malware, phishing content, data leaks, and other threats. As a result, organizations may need to rely on unencrypted metadata and behavioral signals to identify suspicious connections or implement network traffic decryption.

Can teams analyze encrypted traffic without decrypting it?

Analyzing encrypted network traffic without decrypting it includes using metadata, flow behavior, endpoint telemetry, and threat intelligence to infer risk without reading content. For example, an organization might infer that traffic to a known-bad IP address is malicious without reading its contents. However, some controls require payload visibility, so non-decryption methods are not a complete substitute.

When is decryption-based inspection appropriate, and what are the biggest risks?

Decryption-based inspection may be appropriate for high-risk categories like unknown web traffic, file downloads, or access to sensitive systems, when policies and governance are in place. However, decryption introduces risks, such as privacy and compliance concerns, degraded performance, and application breakage if certificate pinning or similar solutions are in place. Organizations should be selective about the traffic they decrypt, test on critical apps, and maintain a clear bypass and exception process.

Encrypted Traffic Inspection with Cato

The Cato SASE Cloud includes a global network of SASE PoPs built around Cato’s Single Pass Cloud Engine (SPACE). Cato converges the security functions of Security Service Edge (SSE) — including FWaaS, CASB, SWG, and DLP — into a single solution, and SPACE allows these security functions to access decrypted data within a single round of traffic decryption and reencryption. When traffic decryption is needed, this minimizes the potential performance and latency impacts.

Cato also offers access to rich contextual data about network flows. This allows organizations to manage security risk without resorting to encryption, further optimizing network performance and security. To learn more about how Cato handles encrypted network traffic, book a demo.