Topic cluster

TLS and proxy security

Termination, passthrough, SNI routing, mutual TLS, interception, request smuggling and SSRF, with the configuration and the failure modes for each.

8 guides · cluster reviewed 8 September 2026

Putting a proxy in the path of encrypted traffic forces a decision: either the proxy holds the private key and can read everything, or it cannot read anything and its usefulness collapses to routing on the parts of the handshake that are still in the clear. Most of the security questions in this cluster follow from that single choice.

The rest follow from a second fact: a proxy is a second HTTP implementation in the path, and two implementations that disagree about the same bytes is the definition of a parsing vulnerability.

Start here by intent#

You want toRead
Decide where TLS terminatesTLS termination, passthrough and re-encryption
Route TLS without decrypting itSNI-based routing
Use client certificates behind a proxyMutual TLS through a proxy
Understand why your corporate laptop breaks pip installTLS interception and corporate root CAs
Know whether your chain is smuggling-safeHTTP request smuggling and proxy desync
Stop your proxy fetching internal URLs on demandSSRF and the proxy layer
Audit an existing deploymentReverse proxy security checklist

The recurring theme#

Every page in this cluster ends up at the same rule: a proxy converts an assertion into a fact for everything behind it. It asserts the client IP, the protocol, the hostname, the client certificate identity, sometimes the authenticated user. Whatever it asserts, the application will believe. That is why the trust boundary has to be a real network boundary, enforced by firewall rules and header stripping, and not just a naming convention.

Every guide in this cluster#