Encryption in all Google Cloud regions
All VM-to-VM traffic within a VPC network and peered VPC networks is encrypted. This includes VM-to-VM traffic within physical boundaries (that is, intra-cluster traffic).
Encryption between GFEs and backends
For the following load balancer types, Google automatically encrypts traffic between Google Front Ends (GFEs) and backends that reside within Google Cloud VPC networks:
- HTTP(S) Load Balancing
- TCP Proxy Load Balancing
- SSL Proxy Load Balancing
Secure backend protocol options
When you create a backend service, you select a backend service protocol. The following backend service protocols provide secure connectivity to backends:
- For HTTP(S) Load Balancing: HTTPS and HTTP/2
- For Internal HTTP(S) Load Balancing: HTTPS and HTTP/2
- For SSL Proxy Load Balancing: SSL
- For Traffic Director: HTTPS and HTTP/2
When HTTP(S) Load Balancing or SSL Proxy Load Balancing connects to a backend using a secure protocol, the GFE is the HTTPS or SSL client. When Internal HTTP(S) Load Balancing connects to a backend using a secure protocol, the Envoy proxy is the HTTPS client.
When a client-side proxy configured using Traffic Director connects to a backend using a secure backend service protocol, the client-side proxy is the SSL or HTTPS client.
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 Traffic Director) to the backend instances.
When the load balancer connects to a backend instance that is outside of Google 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.
When a GFE starts a TLS session to backends, the GFE doesn't use the Server Name Indication (SNI) extension.
When a GFE connects to backends that are within Google Cloud, the GFE accepts any certificate your backends present. GFEs do not perform certificate validation. For example, the certificate is 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.
subjectAlternativeNameattributes don't match a
Hostheader or DNS PTR record.
Secure frontend protocols
When you use a target HTTPS or target SSL proxy as part of your configuration, Google Cloud uses a secure frontend protocol.
HTTP(S) Load Balancing and SSL Proxy Load Balancing use Google's BoringCrypto library. For FIPS 140-2 details, see NIST Cryptographic Module Validation Program Certificate #3678.
Internal HTTP(S) Load Balancing uses Google's BoringSSL library. For FIPS 140-2 details, see the Envoy documentation. Google builds Envoy proxies for Internal HTTP(S) Load Balancing in FIPS compliant mode.
Traffic Director supports Envoy proxies that are built in FIPS-compliant mode.