Google Cloud SSL Proxy Load Balancing terminates user SSL (TLS) connections at the load balancing layer, then balances the connections across your instances using the SSL or TCP protocols. Cloud SSL proxy is intended for non-HTTP(S) traffic. For HTTP(S) traffic, HTTP(S) load balancing is recommended instead.
SSL Proxy Load Balancing supports both IPv4 and IPv6 addresses for client traffic. Client IPv6 requests are terminated at the load balancing layer, then proxied over IPv4 to your backends.
With SSL (TLS) proxying for your SSL traffic, you can terminate SSL sessions at the load balancing layer, then forward the traffic to your virtual machine instances using SSL (recommended) or TCP.
SSL proxy is a load balancing service that can be deployed globally. You can deploy your instances in multiple regions, and the load balancer automatically directs traffic to the closest region that has capacity. If the closest region is at capacity, the load balancer automatically directs new connections to another region with available capacity. Existing user connections remain in the current region.
Note that global load balancing requires that you use the Premium Tier of Network Service Tiers, which is the default tier. Otherwise, load balancing is handled regionally.
For the best security, use end-to-end encryption for your SSL proxy deployment. To do this, configure your backend service to accept traffic over SSL. This ensures that the client traffic decrypted at the SSL proxy layer is encrypted again before being sent to the backend instances. This end-to-end encryption requires you to provision certificates and keys on your instances so they can perform SSL processing.
SSL proxy benefits:
- Intelligent routing — the load balancer can route requests to backend locations where there is capacity. In contrast, an L3/L4 load balancer must route to regional backends without paying attention to capacity. The use of smarter routing allows provisioning at N+1 or N+2 instead of x*N.
- Better utilization of the virtual machine instances — SSL processing can be very CPU intensive if the ciphers used are not CPU efficient. To maximize CPU performance, use ECDSA SSL certs, TLS 1.2 and prefer the ECDHE-ECDSA-AES128-GCM-SHA256 cipher suite for SSL between the load balancer and your instances.
- Certificate management — Your customer-facing SSL certificates can be either certificates that you obtain and manage yourself (self-managed certificates), or certificates that Google obtains and manages for you (Google-managed certificates). You only need to provision certificates on the load balancer itself. On your virtual machine instances, you can simplify management by using self-signed certificates.
- Security patching — If vulnerabilities arise in the SSL or TCP stack, we will apply patches at the load balancer automatically in order to keep your instances safe.
- SSL Proxy Load Balancing supports ports 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, and 5222. When you use Google-managed SSL certificates with SSL Proxy Load Balancing, the frontend port for traffic must be 443 to enable the Google-managed SSL certificates to be provisioned and renewed.
- You can use SSL policies with SSL Proxy Load Balancing.
- While choosing to send the traffic over unencrypted TCP between the load balancing layer and instances enables you to offload SSL processing from your instances, it also comes with reduced security between the load balancing layer and instances and is therefore not recommended.
- SSL proxy can handle HTTPS, but this is not recommended. You should instead use HTTPS load balancing for HTTPS traffic. See the FAQ for details.
- You can create SSL policies
- SSL proxy load balancers do not support client certificate based authentication, also known as mutual TLS authentication.
The following sections describe how SSL Proxy Load Balancing works.
Google Cloud Load Balancing with SSL proxy
With SSL Proxy Load Balancing, SSL connections are terminated at the load balancing layer then proxied to the closest available instance group.
In this example, traffic from users in Iowa and Boston is terminated at the load balancing layer, and a separate connection is established to the selected backend instance.
GCP creates special routes not in your VPC network for health checks. For complete information on this, read Load balancer return paths.
Geographic control over where TLS is terminated
The SSL Proxy load balancer terminates TLS in locations that are distributed globally, so as to minimize latency between clients and the load balancer. If you require geographic control over where TLS is terminated, you should use GCP Network Load Balancing instead, and terminate TLS on backends that are located in regions appropriate to your needs.
The SSL proxy load balancers are reverse proxy load balancers. The load balancer terminates incoming connections, and then opens new connections from the load balancer to the backends. The reverse proxy functionality is provided by the Google Front Ends (GFE).
The firewall rules that you set block traffic from the GFEs to the backends, but do not block incoming traffic to the GFEs.
The SSL proxy load balancers have a number of open ports to support other Google services that run on the same architecture. If you run a security or port scan against the external IP address of your load balancer, additional ports appear to be open.
This does not affect SSL proxy load balancers. External forwarding rules, which are used in the definition of an SSL load balancer, can only reference TCP ports 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, and 5222. Traffic with a different TCP destination port is not forwarded to the load balancer's backend.
When should I use HTTPS load balancing instead of SSL Proxy Load Balancing?
Although SSL proxy can handle HTTPS traffic, HTTPS Load Balancing has additional features that make it a better choice in most cases.
HTTPS load balancing has the following additional functionality:
- Negotiates HTTP/2 and SPDY/3.1
- Rejects invalid HTTP requests or responses
- Forwards requests to different instance groups based on URL host and path
- Integrates with Cloud CDN
- Spreads the request load more evenly among instances, providing better instance utilization. HTTPS load-balances each request separately, whereas SSL proxy sends all bytes from the same SSL or TCP connection to the same instance
SSL Proxy Load Balancing for Google Cloud can be used for other protocols that use SSL, such as Websockets and IMAP over SSL.
Can I view the original IP address of the connection to the load balancing layer?
Yes. You can configure the load balancer to prepend a PROXY protocol version 1 header to retain the original connection information. See Update proxy protocol header for the proxy for details.