TLS Interception at a Forward Proxy — 2D

Proxy Policy

TLS Inspection (decrypt & classify)

Block: Malware / C2

Block: Restricted content

Block: Ad / tracker beacons

Connection rate 4 / s

Decrypt+classify+re-encrypt latency 8 ms

Packet speed 1.0×

Traffic mix (rest is safe)

Malware / C2 5%

Restricted content 10%

Ad / tracker beacons 13%

Live Telemetry

Inspected

Blocked

Threats caught

Blind bypass

Added latency

0 ms

In flight

opaque TLS tunnel
decrypted at proxy (safe)
decrypted → policy blocked
re-encrypted → origin

How it works

A forward TLS-inspecting proxy sits between the client and the open internet as two separate, independently negotiated TLS sessions rather than one continuous encrypted pipe:

Client  ⇄TLS-1⇄  Proxy  ⇄TLS-2⇄  Server

TLS-1: proxy presents a leaf cert signed by an
       internal CA the client already trusts
       (pushed via MDM / group policy).
TLS-2: proxy acts as a normal TLS client toward
       the real origin, validating ITS chain
       normally (hostname, expiry, revocation).

Because the proxy terminates TLS-1 itself, it holds the plaintext for the short window between the two sessions and can classify it — malware/C2 signatures, DLP rules, content category, tracker domains — before deciding whether to re-encrypt and forward on TLS-2, or drop the connection.

decision(pkt) =
  ALLOW   if inspect=off
  BLOCK   if inspect=on AND category ∈ policy.blocked
  ALLOW   if inspect=on AND category ∉ policy.blocked

added_latency ≈ t(decrypt) + t(classify) + t(re-encrypt)

Inspection off — the tunnel stays opaque end-to-end; the proxy forwards bytes it cannot read, so a malicious or policy-violating connection sails through unseen. This is the real trade-off orgs weigh: visibility vs. the added trust concentrated in one CA and one box.
Inspection on — every connection is classified against the active policy toggles before being re-encrypted toward the server, at the cost of processing latency and a privacy footprint the proxy operator must handle responsibly.
Threats caught counts connections that inspection correctly blocked; blind bypass counts connections that would have matched a block rule but slipped through because inspection was off — the concrete cost of flying blind.
The traffic mix sliders set the live probability that a spawned connection belongs to each category (remainder is "safe"); the latency slider is the actual per-connection decrypt+classify+re-encrypt cost fed straight into the "Added latency" telemetry and the latency-history chart below, rather than a fixed constant.

Client Proxy (TLS terminate) Origin server

drag to pan · scroll / pinch to zoom

Added latency history

Connections by category (allowed / blocked)

TLS Interception at a Forward Proxy — 2D