TLS inspection overview

Cloud Next Generation Firewall offers a Transport Layer Security (TLS) interception and decryption service that can inspect encrypted and unencrypted traffic for network attacks and disruptions. TLS connections are inspected on both inbound and outbound connections, including traffic to and from the internet and traffic within Google Cloud.

Cloud NGFW decrypts the TLS traffic to enable the firewall endpoint to perform Layer 7 inspection, such as intrusion prevention, in your network. After the inspection, Cloud NGFW re-encrypts the traffic before sending it to its destination.

Cloud NGFW uses Google-managed Certificate Authority Service (CAS) to generate short-lived intermediate certificates. Cloud NGFW uses these intermediate certificates to generate the certificates that are required to decrypt the intercepted traffic. You set up Certificate Authority (CA) pools, and optionally, trust configs, to store and maintain a list of trusted CA certificates.

This page provides a detailed overview of Cloud NGFW's TLS inspection capabilities.

Specifications

  • Cloud NGFW supports TLS protocol versions 1.0, 1.1, 1.2, and 1.3.

  • Cloud NGFW supports the following TLS cipher suites:

    IANA value Cipher suite name
    0xCCA9 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
    0xCCA8 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
    0xC02B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
    0xC02F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    0xC02C TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    0xC030 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    0xC009 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
    0xC013 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
    0xC00A TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
    0xC014 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
    0x009C TLS_RSA_WITH_AES_128_GCM_SHA256
    0x009D TLS_RSA_WITH_AES_256_GCM_SHA384
    0x002F TLS_RSA_WITH_AES_128_CBC_SHA
    0x0035 TLS_RSA_WITH_AES_256_CBC_SHA
    0x000A TLS_RSA_WITH_3DES_EDE_CBC_SHA

  • Cloud NGFW uses a TLS inspection policy to set up TLS inspection on a firewall endpoint.

    You set up CA pools and, optionally, trust configs to generate trusted TLS certificates for TLS clients. Optionally, you can also set up trust configs to store and maintain trusted CA certificates. You include the configuration information about CA pools and trust configs in a TLS inspection policy. This policy is then attached to the firewall endpoint and target Virtual Private Cloud (VPC) network and is used to decrypt the traffic you want to inspect.

    To learn more about how to set up TLS inspection in Cloud NGFW, see Set up TLS inspection.

  • A TLS inspection policy and a CA pool are both regional resources. Therefore, you must create a CA pool and a TLS inspection policy for each region where you're enabling TLS inspection.

  • If you want to use trust configs in your TLS inspection policy, make sure the trust config and the TLS inspection policy are in the same region.

Role of certificate authority in TLS inspection

Cloud NGFW intercepts TLS traffic by dynamically generating certificates for clients. These certificates are signed by intermediate CAs that are configured within the firewall endpoint. These intermediate CAs are signed by CA pools within CA Service. Cloud NGFW generates new intermediate CAs every 24 hours.

Each time a client establishes a TLS connection, Cloud NGFW intercepts the connection and generates a certificate for the requested server name for the return back to the client. Cloud NGFW can also validate privately signed backend certificates by using a trust config. You can add trusted certificates to a Certificate Manager trust config.

You add trust config and CA pool configurations to a TLS inspection policy. This policy is then added to the firewall endpoint association and is used to decrypt the intercepted traffic.

The CAs stored in CA Service are backed by the Hardware Security Module (HSM) and generate audit logs with each use.

The short-lived intermediate CAs generated by Cloud NGFW are stored only in memory. Each server certificate signed by an intermediate CA does not result in an audit log from CA Service. Also, because server certificates are not generated directly by CA Service, any issuance policies or name constraints configured in the CA pool don't apply to server certificates generated by Cloud NGFW. Cloud NGFW does not enforce these constraints when generating server certificates with intermediate CAs.

Firewall policy rule --tls-inspect flag

To enable decryption of the traffic matching the configured firewall policy rules, use the --tls-inspect flag. When you configure the --tls-inspect flag in the firewall policy rule, Cloud NGFW generates a new server certificate for matched TLS traffic. Intermediate CAs within Cloud NGFW sign this certificate. These intermediate CAs are, in turn, signed by CA pools within CA Service. This certificate is then presented to the client, and a TLS connection is established. The generated certificate is cached for a short time for subsequent connections to the same host.

Limitations

Cloud NGFW does not support QUIC, HTTP/3, or PROXY protocol traffic with TLS inspection.

What's next