# What Is SSL Offloading (TLS offloading)? Definition and Examples

> SSL offloading is moving the CPU work of TLS handshakes and encryption from application servers to a dedicated proxy, load balancer or hardware device.

Source: https://ssl.sh/glossary/ssl-offloading/
Last updated: 2026-11-10

SSL offloading is the performance and operations motive behind terminating TLS in front of an application. A dedicated component, such as a load balancer, application delivery controller, reverse proxy, or a server with a cryptographic accelerator or [HSM](https://ssl.sh/glossary/hsm/), performs the handshakes, holds the certificates and encrypts and decrypts traffic, so application servers handle only HTTP. Two variants are common: pure offloading, where traffic to the backend is plaintext, and SSL bridging (re-encryption), where the proxy decrypts, inspects or routes the request and then opens a new TLS connection to the backend.

## Why it matters
The expensive part of TLS is the public-key operation in each handshake; bulk encryption with [AES-GCM](https://ssl.sh/glossary/aes-gcm/) is cheap on CPUs with AES hardware instructions, and [ECDSA](https://ssl.sh/glossary/ecdsa/) certificates make handshakes cheaper than RSA ones. On modern hardware the benefit of offloading is therefore often less about CPU than about managing certificates, renewal, protocol versions and cipher policy in one place. The trade-off is the plaintext hop. Pure offloading is acceptable only on a trusted, isolated network segment; compliance requirements, shared cloud networks and zero-trust designs usually call for bridging. When bridging, the proxy must verify the backend's certificate, otherwise the second hop is open to interception.

## Example
Bridging with nginx. nginx does not verify upstream certificates by default, so verification has to be switched on:

```nginx
location / {
    proxy_pass https://backend.internal:8443;
    proxy_ssl_server_name on;
    proxy_ssl_name backend.internal;
    proxy_ssl_verify on;
    proxy_ssl_trusted_certificate /etc/nginx/internal-ca.pem;
}
```

For pure offloading, `proxy_pass http://10.0.0.11:8080;` replaces the upstream TLS settings.

## Common misconceptions
- **Offloading is required because TLS is too heavy for application servers.** With AES hardware support and ECDSA keys the overhead on modern servers is usually modest; decide based on architecture and certificate management.
- **`proxy_pass https://` means the backend is authenticated.** nginx encrypts the hop but skips certificate verification unless `proxy_ssl_verify on` is set.
- **Offloading and termination are the same thing.** [TLS termination](https://ssl.sh/glossary/tls-termination/) names where the client's TLS ends; offloading is the decision to put that work on dedicated infrastructure, with or without re-encryption.

## Related terms

- [TLS 终止](https://ssl.sh/zh/glossary/tls-termination/): TLS 终止是指网络路径上客户端 TLS 连接结束并被解密的位置，可以是 CDN 边缘、负载均衡、反向代理，也可以是应用服务器本身。
- [反向代理](https://ssl.sh/zh/glossary/reverse-proxy/): 反向代理是代表后端服务器接收客户端连接、再把请求转发给后端的服务器，通常同时承担 TLS 终止。
- [HSM](https://ssl.sh/zh/glossary/hsm/): HSM 是一种防篡改的硬件设备，在内部生成、保存并使用密钥，私钥不会以明文形式离开设备。
- [ECDSA](https://ssl.sh/zh/glossary/ecdsa/): ECDSA 是基于椭圆曲线的数字签名算法，在 TLS 证书中作为 RSA 的替代方案，密钥和签名更小、签名运算更快。
- [AES-GCM](https://ssl.sh/zh/glossary/aes-gcm/): AES-GCM 是以伽罗瓦/计数器模式运行的 AES 分组密码，属于 AEAD 算法，用计数器模式加密、用 GHASH 认证标签保证完整性。
- [私有 CA](https://ssl.sh/zh/glossary/private-ca/): 私有 CA 是企业为自己的系统和设备搭建的证书颁发机构，其根证书只在企业主动安装的设备上受信任。