A Snowflake-Inspired WebRTC Proxy PoC for Filter Evasion (Part 2): Building the TURN/TURNS and DPI Testbed

In Part 1, we showed how a Snowflake-inspired WebRTC DataChannel proxy can bypass a client-side DNS filter by offloading destination resolution to a remote proxy peer. But what happens when defenders deploy Deep Packet Inspection (DPI), strict egress firewalls, and TLS-inspecting forward proxies? Part 2 defines the controlled testbed and evidence standard for evaluating WebRTC DataChannels under Coturn TURN/TURNS relaying, an explicit mitmproxy HTTPS baseline, and offline Suricata/Zeek analysis. The harness is implemented, but the P2-A through P2-F measurements remain in progress; this article separates protocol expectations from findings that still require captured evidence.

Recap & The Threat Model Beyond DNS

In Part 1, we tested a bounded WebRTC proxy in Go inspired by the Tor Project's Snowflake pluggable transport. We established that client-side DNS filtering is completely ineffective when a client tunnels requests over a WebRTC DataChannel, because the client never queries its local DNS resolver for the destination domain.

However, enterprise networks rarely rely on DNS filtering alone. Layered network defenses typically include:

Egress Filtering: Dropping outbound UDP traffic and restricting connections to TCP ports 80 and 443.
NAT Traversal & Relaying: Deploying TURN (Traversal Using Relays around NAT) servers when direct peer-to-peer UDP paths fail.
Deep Packet Inspection (DPI): Network security monitoring tools (Suricata, Zeek) that detect STUN handshakes, DTLS parameters, and tunnel anomalies.
SSL/TLS Bumping: Intercepting encrypted sessions via forward proxies using trusted enterprise root certificates.

To measure how WebRTC DataChannels interact with these inspection layers, we built a controlled testbed pinned to Coturn 4.12.0, mitmproxy 12.2.3, Suricata 8.0.5, and Zeek 8.0.8. Smoke validation establishes that the scaffold operates; it is not a completed transport measurement.

Part 2 Testbed Architecture

The test matrix defines the following transport and interception paths:

[Client] --- (A) Direct UDP (STUN / Host / Server-Reflexive) ----> [Proxy]
[Client] --- (B) Explicit Forward Proxy (mitmproxy :8081) --------> [Proxy]
[Client] === (C) TURN Relay over UDP (:3478) =====================> [Coturn] ===> [Proxy]
[Client] === (D) TURN Relay over TCP (:3478) =====================> [Coturn] ===> [Proxy]
[Client] === (E) TURNS Relay over TLS/TCP (:443) =================> [Coturn] ===> [Proxy]

The lab scaffold enforces a strictly bounded environment: Coturn denies all IPv4 and IPv6 relay destinations by default, allowing only explicit testbed peer addresses. Certificates for turns: over port 443 are generated locally via cmd/labcert with temporary validity.

Measurement Status (P2-A through P2-F)

As of this update, no P2-A through P2-F result has enough committed evidence to be called a finding. The repository controls matrix therefore records every case as Not run.

Each completed run must include its UTC window, exact commit and configuration, selected ICE candidate pair, client/proxy/Coturn completion status, packet-capture SHA-256 hash, relevant Coturn and mitmproxy logs, Suricata/Zeek output, and documented blind spots.

LAB_ICE_POLICY=relay requests relay-only ICE candidates, but configuration alone does not prove that the intended TURN transport carried the session. The logged selected candidate pair is required.

The regular mitmproxy service is an explicit HTTP(S) proxy baseline. It is not an inline TURN or DTLS inspection appliance. A P2-F claim requires a separately documented transparent or appliance topology and evidence from both sides of that gateway.

Current status and future sanitized results are tracked in FINDINGS_PART2.md.

Protocol Deep Dive: What Network Monitors Actually See

The following are protocol-derived expectations to test, not recorded outcomes from this lab:

1. TURN UDP (:3478) — High Metadata Exposure

While the inner SCTP/DataChannel application data is protected by DTLS encryption, the TURN outer layer transmits all signaling in plaintext. Network sensors observe unencrypted STUN ALLOCATE requests, transaction IDs, requested lifetimes, peer IP addresses in CREATE_PERMISSION, and DTLS handshake parameters (ClientHello, self-signed certificates, cipher suites).

2. TURN TCP (:3478) — Framing over Stream Transport

TURN over TCP carries STUN messages and ChannelData over a TCP stream using TURN's message framing rules. Blocking UDP alone may cause an implementation to try this path, but successful traversal depends on the actual egress policy. Without outer TLS, compatible Layer 7 tooling may identify TURN signaling and the relayed DTLS exchange.

3. TURNS over TLS/TCP (:443) — Cryptographic Encapsulation

TURNS wraps the STUN/TURN exchange and relayed payload inside an outer TLS session. A passive sensor generally loses visibility into the inner TURN and DTLS bytes, but the flow is not necessarily indistinguishable from HTTPS: destination policy, SNI when exposed, ALPN behavior, TLS fingerprints, timing, and byte patterns may remain useful. Certificate visibility also depends on the negotiated TLS version and observation point.

The TLS Forward Proxy Interception Boundary

The test plan distinguishes the architectural boundary of explicit forward proxies:

Standard explicit forward proxies (such as corporate Secure Web Gateways or mitmproxy in regular mode) rely on client applications explicitly sending HTTP CONNECT tunnel requests. Because WebRTC engines communicate via direct UDP sockets or direct TLS sockets to TURN relays, they completely bypass explicit proxies.

Testing interception of TURNS on port 443 requires an authorized transparent inline gateway or appliance that can handle non-HTTP TLS, plus a client trust and certificate-validation arrangement compatible with the TURN implementation. A routing redirect or trusted root alone does not prove successful decryption. DTLS interception requires a separate UDP-capable path and is not supplied by the regular mitmproxy baseline.

Suricata & Zeek Signatures: How Defenders Can Detect WebRTC Proxies

The testbed is designed to evaluate several candidate detection signals. Their reliability and false-positive rate must be measured before deployment:

STUN/TURN Signatures: Suricata protocol parsers (app-layer-protocol:stun) can flag ALLOCATE methods hitting unauthorized public IP addresses.
DTLS from Non-Browser Binaries: Zeek ssl.log logs DTLS connections (version:DTLS 1.2). Correlating DTLS handshakes with endpoint process execution telemetry reveals non-browser binaries executing WebRTC stacks.
Flow Entropy & Symmetrical Throughput: Zeek conn.log metrics showing long-lived, high-entropy bidirectional flows on port 443 with sustained packet cadence but no HTTP request/response semantics.
SNI & Certificate Validation: Enforcing strict domain allowlisting on port 443 and alerting on unknown, dynamic, or self-signed certificates.

Comprehensive Controls Comparison Matrix

The following control behaviors are hypotheses for the P2 matrix rather than completed results:

Client-Side DNS Filter: Ineffective against all modes because destination domain resolution is performed solely by the remote proxy host.
Egress UDP Firewall: Expected to block direct UDP and TURN UDP. TURN-TCP or TURNS may remain possible only when destination, port, and Layer 7 egress policy permit them.
Explicit Forward Proxy: Ineffective against direct WebRTC and TURNS sockets unless transparent inline redirection is enforced at the network routing layer.
Layer 7 SNI / Domain Filtering: Effective against TURNS on port 443 if outbound connections to unknown or unauthorized SNIs are denied.
Network Security Monitoring (Zeek/Suricata): May expose STUN headers, DTLS handshakes, TLS metadata, or flow anomalies depending on transport and parser coverage; absence of an alert is inconclusive.

Conclusion & Key Takeaways

Part 1 demonstrated the DNS-resolution boundary in the bounded lab. Part 2 now provides the harness and evidence standard needed to test whether particular egress firewalls, explicit proxies, and transparent inspection systems block, expose, or permit TURN-TCP and TURNS. Those outcomes remain pending until the matrix is executed and documented.

For network defenders, effective mitigation requires a defense-in-depth strategy:

1. Block unapproved outbound UDP traffic at the network edge to prevent direct peer-to-peer connections and raw TURN relays.

2. Restrict outbound port 443 connections using Layer 7 SNI inspection and domain allowlisting.

3. Monitor endpoint telemetry for non-browser processes initiating WebRTC and DTLS network sockets.

4. Use Zeek and Suricata flow analytics to flag long-lived, high-entropy symmetric connections on port 443.

Repository: snowflake-inspired-webrtc-proxy-lab

Built in Go. Run only in owned or explicitly authorized lab environments.