Selective MITM: Why Iddio Doesn't Intercept Everything

The Problem with Intercepting Everything

When building a local security gateway, the initial instinct is to route all outgoing HTTPS traffic through a Man-in-the-Middle (MITM) proxy. Tools like pf (Packet Filter) make this trivial to enforce at the OS level.

However, intercepting everything introduces two severe problems for developers:

1. Latency Overhead. Every intercepted connection requires two TLS handshakes: one with the locally minted certificate, and one with the actual upstream server. That adds tens of milliseconds of latency per connection. A busy developer workstation opens thousands of HTTPS connections daily, quickly turning this overhead into a noticeable drag.
2. Certificate Pinning. Many applications hardcode or "pin" their expected upstream certificates. When they detect the proxy's minted certificate instead of the pinned one, they abort the connection. MITMing traffic for apps with strict pinning (like many communication or cloud sync tools) causes them to fail opaquely, leaving developers frustrated.

Selective Inspection

To solve this, Iddio uses a selective MITM architecture. All traffic still routes through the gateway to maintain the "unavoidable path" security property, but the proxy only intercepts traffic destined for hosts the developer has explicitly opted to inspect.

This mirrors how developers already reason about local network monitors like Wireshark or Little Snitch: "I only want to monitor these specific domains."

The Inspect List

An inspect list embedded directly in the policy configuration drives the decision to intercept. Each supported protocol defines the endpoints it cares about:

kubectl:
  inspect:
    - "*.eks.amazonaws.com"
    - "*.gke.goog"
    - "*.azmk8s.io"

The default policy seeds inspect entries only for the infrastructure control planes Iddio ships classifiers for: managed Kubernetes API servers (EKS, GKE, AKS), Google Cloud APIs (*.googleapis.com), and Fly.io. These are visible in the policy file and editable like any other entry. Beyond those seeds, nothing is intercepted — the catch-all generic inspect list ships empty, so general SaaS and API traffic (GitHub, OpenAI, Anthropic, your bank) passes through untouched unless you explicitly add it.

Hostname and IP Matching

When a connection arrives, Iddio evaluates the destination against the inspect list. The matching engine supports exact hostnames, suffix wildcards, IPv4, IPv6, and CIDR blocks.

If the destination matches an entry on the list, the proxy initiates the MITM process, classifying the request and applying policy.

If the destination is absent from the inspect list, the gateway acts as a raw TCP proxy. It passes the traffic through untouched, logging only a lightweight connection-metadata row (destination host and port, why the connection was passed through, and which OS user opened it) to the audit trail. This passthrough path avoids the TLS handshake overhead entirely and completely sidesteps certificate pinning issues for uninspected apps.