TLS inspection overview

Transport Layer Security (TLS)-encrypted web traffic accounts for a large portion of all web traffic, and threat actors can use these encrypted channels to launch malicious attacks. As a result, it is critical to check the TLS-encrypted traffic before forwarding it to its destination.

Secure Web Proxy offers a TLS inspection service that lets you intercept the TLS traffic, inspect the encrypted request, and enforce security policies.

Based on the implemented security rules and the TLS inspection configuration, the Secure Web Proxy solution establishes two secure connections, one with the client and another with the external server. The Secure Web Proxy solution then inspects the traffic between the two secure connections. After successful verification, you can apply the same filtering and security controls to encrypted traffic that you do to unencrypted traffic.

Role of certificate authorities in TLS inspection

To determine if the Secure Web Proxy should inspect a TLS connection, it checks the tls_inspection_enabled flag on its individual security policy rules. If the flag is set, and if a TLS connection is detected, then Secure Web Proxy generates a new server certificate. It sends this certificate to the Certificate Authority Service (CAS) to be signed by your subordinate certificate authority (CA) pool. This certificate is then presented to the client, and a TLS connection is established. The generated certificate is cached for a short time to be used on subsequent connections to the same host.

If you want to inspect TLS traffic, you must generate a server certificate for the host that the client is attempting to connect to. An organization-managed, private CA must sign this server certificate. Only clients configured to trust this private CA trust these generated server certificates. These include browsers and embedded HTTP clients. As a result, TLS inspection can only be used to intercept and inspect TLS connections from clients that your organization has administrative control over.

Not all TLS connections can be successfully intercepted, even on machines over which the organization has administrative control. This is because some clients (particularly those embedded inside other applications) are hardcoded to only accept specific server certificates or those signed by specific CAs (a practice known as certificate pinning). Microsoft Windows, MacOS, and Google Chrome software updates are a few examples. Such connections fail in the presence of TLS inspection. This happens because the public key and the CA chain of the server certificate that Secure Web Proxy presents to the client do not match with the locally stored parameters.

If a rule is configured to inspect TLS traffic, but the client does not trust the inspection certificates that Secure Web Proxy presents, then the connection fails. In these cases, TLS inspection is known to break client-server connections even if the server is trusted. To work around this situation, you can add rules to bypass TLS inspection for specific criteria. You can also restrict TLS inspection to specific destination hosts (by using FQDN), sources (by using Secure Tags, Service Account, or IP address), and by using the SessionMatcher attribute of a rule.

Supported features

Secure Web Proxy TLS inspection supports the following features:

  • Tight integration with CAS, which is a highly available and scalable repository for private CAs.
  • The ability to use your own root of trust if required. You can also use an existing root CA to sign for subordinate CAs held by CAS. If you prefer, you can generate a new root certificate within CAS.
  • Granular decryption criteria by using SessionMatcher within Secure Web Proxy policy rules. This criteria includes matching hosts present in URL lists, regular expressions, IP address ranges, and similar expressions. If required, criteria can be combined with boolean expressions.
  • Each Secure Web Proxy policy can be configured with its own TLS inspection policy and CA pool. Alternatively, multiple Secure Web Proxy policies can share a single TLS inspection policy.

Common use cases

To enable TLS inspection, you can use any of the following methods:

  • Use an existing root CA to sign subordinate CAs held within CAS. A subordinate CA held within CAS is used to sign server certificates generated at runtime.

  • Use an existing root CA held externally (not in CAS) to sign subordinate CAs. When the subordinate CAs are signed by your root CA, you can use them to sign server certificates generated at runtime.

  • Use a root certificate generated within CAS. After you create the root certificate, you create a subordinate CA signed by your new root CA. That subordinate CA is used to sign server certificates generated at runtime.

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