TLS inspection overview

Transport Layer Security (TLS) encrypted traffic accounts for the vast majority of web traffic. Because threat actors often use these encrypted channels to hide malicious activity, it's critical to inspect this traffic before it reaches its destination.

Secure Web Proxy provides an integrated TLS inspection service that lets you intercept and decrypt HTTPS traffic. By gaining visibility into the encrypted request, Secure Web Proxy can apply advanced security policies—such as URL filtering on the full request path and HTTP header inspection—to protect your environment from threats hidden within encrypted tunnels.

How it works

TLS inspection works by establishing two separate encrypted connections, with Secure Web Proxy acting as a secure intermediary.

Client handshake: when a client tries to connect to an external site, such as www.example.com, Secure Web Proxy intercepts the request.
Certificate generation: Secure Web Proxy communicates with the private Certificate Authority Service (CA Service). The proxy generates a temporary certificate for www.example.com in real-time, signed by your organization's private subordinate CA.
Trust validation: the client then receives that temporary certificate.
Inspection point: traffic is decrypted within the Secure Web Proxy instance. At this stage, security policies are applied to the plain-text HTTP data.
Server handshake: Secure Web Proxy then initiates a second TLS connection to the actual destination server. The traffic is re-encrypted and sent to the destination address.

Key features

The Secure Web Proxy TLS inspection service offers a flexible, scalable framework for managing encrypted traffic through the following capabilities:

Integrated private trust: built-in integration with CA Service provides a highly available, Google-managed repository for your private CAs.
Flexible root of trust: use an existing on-premises root certificate authority (CA) to sign subordinate CAs that are hosted in CA Service. You can then generate and manage a completely new root certificate directly within CA Service.
Specific decryption: use SessionMatcher to define precisely which traffic to decrypt. You can trigger the TLS inspection based on the following parameters:
- Website domain names: match specific websites by using regular expressions and domain lists.
- Network criteria: target specific source IP address ranges or Classless Inter-Domain Routing (CIDR) blocks, such as 10.0.0.0/24, to define network boundaries.
- Boolean logic: combine multiple conditions—such as a source IP and a destination URL—to create highly specific security rules.
Scalable policy architecture:
- Dedicated policies: assign a unique TLS inspection policy and CA pool to each Secure Web Proxy policy for strict isolation.
- Shared policies: simplify policy management by sharing a single TLS inspection configuration across multiple proxy policies.
Full Uniform Resource Identifier (URI) visibility: inspect the entire URI (including the domain, path, and query strings, such as www.example.com/downloads/malware.exe) rather than just the domain name.
Precise access control: use TLS inspection to enforce policies for specific paths of a website. For example, you can allow access to www.example.com/documentation, but block www.example.com/uploads.

Role of certificate authorities in TLS inspection

To inspect encrypted traffic, Secure Web Proxy acts as a trusted intermediary. This involves a coordinated process between the proxy, the CA Service, and the client device.

Client trust requirements

TLS inspection is designed for environments where an organization has administrative control over the client devices, such as managed laptops, servers, or virtual machines (VMs).

Private trust anchor: Because Secure Web Proxy presents certificates that are signed by your internal CA rather than a public CA, clients trust the connection only if your private root CA is pre-installed.
Administrative scope: Connections from unmanaged hardware typically trigger Insecure connection warnings because these devices lack your organization's specific trust anchor.

Handle interception failures

Even on managed devices, certain connections can't be intercepted due to certificate pinning. Certificate pinning occurs when an application is hardcoded to accept only a specific public key or a specific public CA chain.

Examples of certificate pinning: common services that use pinning include Windows and macOS system updates, Google Chrome updates, and certain high-security mobile applications.
Result of certificate pinning: when Secure Web Proxy presents its signed certificate, the application detects that the certificate doesn't match its hardcoded expectations and terminates the connection.

Mitigation and precise control

To prevent service disruptions for pinned applications or to maintain privacy for sensitive websites, you can use the SessionMatcher attribute to bypass inspection. You can restrict or skip inspection based on the following parameters:

Destination attributes: specific fully qualified domain names (FQDNs).
Source attributes: secure tags, service accounts, or IP addresses.
Custom logic: use boolean expressions to exclude specific traffic while inspecting the rest of the environment.

Certificate authority configuration methods

To enable TLS inspection, set up your certificate authority (CA) by using any of the following methods:

Subordinate CA in CA Service: use an existing external root CA to sign a subordinate CA stored within Google Cloud.
External root CA: use an external root CA to sign certificates that are generated at runtime through subordinate CAs.
Google-managed root CA: generate a new root certificate directly within CA Service to sign your subordinate CAs.

For more information about these methods, see Create a subordinate CA pool.