Some or all of the information on this page might not apply to Trusted Cloud by S3NS.

Encryption from the load balancer to the backends

Encryption in all Trusted Cloud regions

All VM-to-VM traffic within a VPC network and peered VPC networks is encrypted.

Encryption between proxy load balancers and backends

For some proxy load balancers (see table 1), Google automatically encrypts traffic to the backends that reside within Trusted Cloud VPC networks. This is called automatic network-level encryption. Automatic network-level encryption is only applicable to communications with these types of backends:

Instance groups
Zonal NEGs (GCE_VM_IP_PORT endpoints)

In addition, Trusted Cloud provides secure protocol options to encrypt communication with the backend service.

The regional load balancers use the open source Envoy proxy as a client to the backends. The load balancers support the cipher suites listed in RFC 8446, section 9.1 for TLS 1.3. For TLS 1.2 and earlier, the load balancer supports the cipher suites associated with the COMPATIBLE SSL policy profile.

The following table provides a summary of the proxy load balancers that encrypt traffic to the backends.

**Table 1.** Communications between load balancers and backends
Proxy load balancer	Proxy (client to the backend)	Backend service protocol options
Regional external Application Load Balancer	Envoy proxy	HTTP, HTTPS, and HTTP/2 Choose HTTPS or HTTP/2 if you require auditable encryption in transit to the backends.
Regional internal Application Load Balancer	Envoy proxy	HTTP, HTTPS, and HTTP/2 Choose HTTPS or HTTP/2 if you require auditable encryption in transit to the backends.
Regional external proxy Network Load Balancer	Envoy proxy	TCP
Regional internal proxy Network Load Balancer	Envoy proxy	TCP

Secure backend protocol use cases

A secure protocol to connect to backend instances is recommended in the following cases:

When you require an auditable, encrypted connection from the load balancer (or Cloud Service Mesh) to the backend instances.
When the load balancer connects to a backend instance that is outside of Trusted Cloud (with an internet NEG). Communication to an internet NEG backend might transit the public internet. When the load balancer connects to an internet NEG, the public CA-signed certificate must meet the validation requirements.

Secure backend protocol considerations

When using a secure backend service protocol, keep the following in mind:

Your load balancer's backend instances or endpoints must serve using the same protocol as the backend service. For example, if the backend service protocol is HTTPS, the backends must be HTTPS servers.
If the backend service protocol is HTTP/2, your backends must use TLS. For configuration instructions, see the documentation for the software running on your backend instances or endpoints.
You must install private keys and certificates on your backend instances or endpoints in order for them to function as HTTPS or SSL servers. These certificates don't need to match the load balancer's frontend SSL certificates. For installation instructions, see the documentation for the software running on your backend instances or endpoints.
With the exception of HTTPS load balancers with internet NEG backends, load balancers don't use the Server Name Indication (SNI) extension for connections to the backend.
When a load balancer connects to backends that are within Trusted Cloud, the load balancer accepts any certificate your backends present. In this case, the load balancer performs only minimum certificate validation.

For example, certificates are treated as valid even in the following circumstances:
- The certificate is self-signed.
- The certificate is signed by an unknown certificate authority (CA).
- The certificate has expired or is not yet valid.
- The CN and subjectAlternativeName attributes don't match a Host header or DNS PTR record.
For RSA certificates, starting April 28, 2025, the load balancer will only accept RSA certificates that have the X509v3 Key Usage extension present and include both the Digital Signature and Key Encipherment parameters. For more information, see the associated release note on January 24, 2025.

Secure frontend protocols

When you use a target HTTPS or target SSL proxy as part of your configuration, Trusted Cloud uses a secure frontend protocol.

External Application Load Balancers and external proxy Network Load Balancers use Google's BoringCrypto library. For FIPS 140-2 details, see NIST Cryptographic Module Validation Program Certificate #3678.

Internal Application Load Balancers use Google's BoringSSL library. For FIPS 140-2 details, see the Envoy documentation. Google builds Envoy proxies for internal Application Load Balancers in FIPS compliant mode.