Local vs. Cloud TLS Inspection: Deployment Tradeoffs
- TLS inspection decrypts, inspects, and re-encrypts traffic, so plaintext briefly exists wherever it happens.
- Local inspection gives control over local plaintext and keys; assess cloud-applied services and their processing separately.
- NSA guidance recommends inspecting each session once, inside the enterprise network, without chained proxies.
- Maintain a reviewed exception list for pinned apps, privacy-sensitive categories, and traffic that breaks under inspection.
- Encrypted Client Hello, published as RFC 9849, limits passive visibility and needs deliberate handling.
TLS inspection (often still called SSL inspection) is the process of intercepting a TLS session, decrypting it with an enterprise-trusted certificate, inspecting the content, and re-encrypting it before forwarding it to the destination. Without it, secure web gateways, DLP engines, and sandboxes see only destination metadata. With it, they can detect malware, block data exfiltration, and enforce acceptable use policies inside encrypted sessions.
The decision is not whether to inspect, but where. This guide compares local and cloud TLS inspection across decryption paths, certificate responsibilities, exceptions, logging, and operations.
This article is part of the Hybrid Cloud Security guide.
How TLS inspection works
TLS inspection works by having a trusted proxy terminate the client’s encrypted session, inspect the content, and open a new encrypted session to the destination.
The proxy acts as the server to the client and as the client to the destination:
- The client starts a TLS session toward a website or application.
- The proxy intercepts the connection and presents a certificate for the destination, signed by an enterprise inspection certificate authority (CA) that client devices trust.
- The proxy opens its own TLS session to the real destination and validates that server’s certificate.
- Traffic is decrypted between the two sessions, inspected, and re-encrypted.
This means the proxy holds a very powerful key and handles plaintext for every inspected session. The NSA advisory Managing Risk from Transport Layer Security Inspection recommends minimizing where that happens: perform inspection once, within the enterprise network, and avoid redundant inspection by multiple forward proxies. CISA’s earlier alert on HTTPS interception warned that poorly implemented inspection products can weaken TLS security, for example by failing to validate upstream certificates properly.
Local vs. cloud TLS inspection at a glance
Local inspection keeps plaintext and keys on your infrastructure, while cloud inspection moves them to provider points of presence.
| Factor | Local (on-premises) TLS inspection | Cloud TLS inspection |
|---|---|---|
| Where plaintext exists | Your data center or branch appliances | Provider points of presence |
| Who holds the inspection CA private key | You, optionally in your own HSM | Provider, or you via provider-supported key options |
| Best for | Regulated data, internal traffic, on-site users, OT | Remote users, direct-to-SaaS traffic |
| Latency for on-site users | Depends on local capacity and traffic path | Depends on point-of-presence distance and routing |
| Capacity planning | Yours; decryption is compute-intensive | Provider’s |
| Dependency on external connectivity | None for local web policy enforcement; required for cloud-applied services such as data protection | Required |
| Logs and evidence location | Local logs are configurable; cloud-service evidence follows that service’s storage policy | Provider regions, subject to configuration |
| Operational effort | Hardware sizing, patching, certificate lifecycle | Certificate distribution, exceptions, provider configuration |
Most hybrid organizations use both: local inspection for selected on-site and regulated traffic, and cloud inspection for remote users. Map TLS termination across each path and avoid redundant decryption, including when a local gateway forwards traffic for cloud-applied services.
Decryption paths
Every hybrid design should map each TLS termination and re-encryption point and avoid redundant inspection.
Common paths include:
- Office user to internet: local gateway, or tunneled to a cloud point of presence
- Remote user to internet: cloud point of presence, or backhauled to a local gateway
- User to private app: identify whether and where the selected ZTNA path supports TLS inspection
- Browser session: browser-level controls that see content without network decryption
- Endpoint: agent-based inspection on the device
A risk in hybrid environments is unplanned duplicate decryption. A branch may send traffic through a local proxy and then through a cloud service that terminates TLS again. Document each required inspection stage, protect each plaintext boundary, and remove redundant stages that add exposure or troubleshooting complexity.
Certificate responsibilities
TLS inspection is only as trustworthy as the certificates behind it, so assign clear ownership for each part of the certificate lifecycle:
- Inspection CA creation and protection. Document where the private key lives, who can access it, and whether an HSM is required. Confirm supported HSM integrations for each local gateway or cloud service and its product version; do not assume support.
- Distribution. How the CA is installed in operating system and browser trust stores on managed devices, and what happens on unmanaged devices.
- Rotation. The schedule and process for replacing the inspection CA without an outage.
- Upstream validation. Confirm the proxy rejects invalid, expired, or revoked destination certificates rather than masking them from users.
- Protocol support. TLS 1.3 (RFC 8446) should be inspected natively, not downgraded.
Traffic exceptions
No organization should decrypt everything, so maintain a documented, regularly reviewed exception list:
| Exception type | Reason | Typical handling |
|---|---|---|
| Certificate-pinned applications | Inspection breaks the connection | Bypass by destination; apply reputation and category controls |
| Health, financial, and personal categories | Employee privacy, legal and works council requirements | Bypass decryption; still enforce category policy |
| Mutual TLS and client-certificate authentication | Proxy cannot present the client certificate | Bypass or use a supported pass-through |
| Update services and some OT protocols | Stability and vendor support | Bypass by destination with restricted access |
| QUIC and HTTP/3 (RFC 9000) | Many proxies cannot inspect QUIC | Block QUIC so browsers fall back to TLS over TCP, or confirm native support |
Review exceptions quarterly. Stale bypasses are a common blind spot.
Encrypted Client Hello and what it changes
Encrypted Client Hello hides the destination hostname from passive observers, so SNI-based visibility and some bypass decisions need rethinking.
Encrypted Client Hello was published as RFC 9849 in 2026. ECH encrypts the part of the TLS handshake that previously revealed the destination hostname (the Server Name Indication) and other fields. Passive tools that classify traffic by reading the SNI lose that visibility for ECH-enabled sites.
Explicit proxies that terminate TLS are in a different position, because they establish their own sessions to destinations. Even so, ECH has operational implications:
- Browsers may send ECH-like extensions even when ECH is not in use, so inspection products need to handle them correctly.
- The RFC notes that in managed enterprise settings, one approach is to disable ECH through group policy and rely on clients honoring that setting.
- Category and reputation decisions that depended on SNI for bypassed traffic need an alternative, such as DNS-layer controls or explicit proxy configuration.
Confirm your inspection vendor’s ECH roadmap and test behavior with current browser versions.
Logging
Inspection logs can contain URLs, identities, and DLP evidence, so their content, location, and access need explicit decisions:
- Which fields are logged for decrypted versus bypassed traffic
- Where logs are stored, and whether they may leave a jurisdiction
- Retention periods, and who can access full content evidence
- Which events are forwarded to the SIEM
Local inspection makes it easier to keep logs and evidence in-country. Cloud inspection requires confirming provider log regions and access controls. See Data Sovereignty in Hybrid Cloud Security.
Operational tradeoffs
Local inspection trades operational effort for control, cloud inspection trades control for simplicity, and hybrid inspection needs one policy engine to work.
Local inspection requires sizing appliances for decryption at peak, keeping inspection engines patched, and planning hardware or virtual capacity growth. In return, it gives full control over plaintext, keys, and logs for locally inspected traffic, and local enforcement of web and private application policy continues during a WAN or cloud interruption, while services applied in the vendor cloud pause until connectivity returns.
Cloud inspection shifts capacity planning and engine updates to the provider. It still requires certificate distribution, exception management, and policy tuning, and it introduces a dependency on provider availability and connectivity.
Hybrid inspection combines both, but only works well with one policy engine. If local and cloud gateways have separate exception lists and DLP rules, users will be treated differently depending on location.
How Skyhigh approaches local and cloud inspection
Skyhigh inspects TLS locally where compliance requires it and in the cloud for remote users, under one policy.
Skyhigh Hybrid SSE Mesh runs SSL/TLS decryption and inspection locally on the organization’s own appliances where compliance requires it, and in Skyhigh cloud points of presence for remote users, with one policy engine across both. Secure Web Gateway and Zero Trust Access are enforced natively on the gateway, while data protection policy is applied in the Skyhigh cloud on traffic the gateway forwards. Web traffic decrypted on the on-premises gateway is inspected and re-encrypted there for local web policy enforcement. Where a policy uses a cloud-applied service such as data protection, the gateway forwards the relevant traffic to the Skyhigh cloud, where the same policy is applied. Agentless Secure Browser Controls add WebSocket-aware inspection of AI and messaging traffic in the browser session.
Sources
- NSA. Managing Risk from Transport Layer Security Inspection (November 2019). https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
- CISA. “HTTPS Interception Weakens TLS Security” (Alert TA17-075A, March 2017). https://www.cisa.gov/news-events/alerts/2017/03/16/https-interception-weakens-tls-security
- IETF. RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. https://www.rfc-editor.org/rfc/rfc8446.html
- IETF. RFC 9849: TLS Encrypted Client Hello. https://www.rfc-editor.org/rfc/rfc9849.html
- IETF. RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport. https://www.rfc-editor.org/rfc/rfc9000.html
- Skyhigh Security. “Adopting Hybrid Just Got Easier With Skyhigh SSE Platform” (October 3, 2024). https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html
- Skyhigh Security. “Modernizing Your Symantec Edge Secure Web Gateway With Skyhigh Hybrid SSE Mesh” (July 15, 2026). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html