TLS termination proxy

TLS termination proxies can be used to:

• secure plaintext communications over untrusted networks by tunnelling them in (D)TLS,
• allow inspection of encrypted traffic by an intrusion detection system to detect and block malicious activities,
• allow network surveillance and analysis of encrypted traffic,
• enable otherwise unsupported integration with other applications that provide additional capabilities such as content filtering or Hardware security modules,
• enable (D)TLS protocol versions, extensions, or capabilities (e.g., OCSP stapling, ALPN, DANE, CT validation, etc.) unsupported by client or server applications to enhance their compatibility and/or security,
• work around buggy or insecure (D)TLS implementations in client or server applications to improve their compatibility and/or security,
• provide additional certificate-based authentication unsupported by server and/or client applications or protocols,
• provide an additional defense-in-depth layer for centralised control and consistent management of (D)TLS configuration and associated security policies, and
• reduce the load on the main servers by offloading the cryptographic processing to another machine.

TLS termination proxies can provide three connectivity patterns:^[3]

• TLS Offloading: Terminates an inbound encrypted (D)TLS connection from a client and forwards communications over a plaintext connection to the server.
• TLS Encryption: Accepts an inbound plaintext connection from a client and forwards communications over an encrypted (D)TLS connection to the server.
• TLS Bridging: Terminates two encrypted (D)TLS connections to allow inspection and filtering of traffic. The proxy decrypts the inbound (D)TLS connection from the client and re-encrypts it using a separate (D)TLS connection to the server.

Combining a TLS Encrypting proxy in front of a client with a TLS Offloading proxy in front of a server can allow (D)TLS encryption and authentication for protocols and applications that do not otherwise support it, with the two proxies maintaining a secure (D)TLS tunnel over untrusted network segments between client and server.

A proxy used by clients as an intermediary gateway for all outbound connections is typically called a Forward proxy, while a proxy used by servers as an intermediary gateway for all inbound connections is typically called a Reverse proxy. Forward TLS bridging proxies that allow an intrusion detection system to analyse all client traffic are typically marketed as "SSL Forward Proxy".^[4][5][6]

TLS Offloading and TLS Bridging proxies typically need to authenticate themselves to clients with a digital certificate using either PKIX or DANE authentication. Usually, the server operator supplies its reverse proxy with a valid certificate for use during the (D)TLS handshake with clients. A forward proxy operator, however, must create their own private CA, install it into the trust store of all clients, and have the proxy generate a new certificate signed by the private CA in real time for each server that a client attempts to connect to.

When network traffic between a client and server is routed via a proxy, it can operate in transparent mode by using the client's IP address instead of its own when connecting to the server, and using the server's IP address when responding to the client. If a Transparent TLS Bridging Proxy possesses a valid server certificate, neither the client nor the server would be able to detect the proxy's presence. An adversary who has compromised the private key of the server's digital certificate, or who can use a compromised or coerced PKIX CA to issue a new valid certificate for the server, could perform a man-in-the-middle attack by routing TLS traffic between the client and server through a Transparent TLS Bridging Proxy. This would grant the adversary the ability to copy decrypted communications (including logon credentials) and modify the content of communications on the fly without detection.

• TLS acceleration