webrtc-pluggable   WebRTC-based pluggable transport

Simulations extending the ENEM19 game-theory framework show that ephemeral proxy schemes (modeled on Snowflake/Lantern) effectively neutralize both the "optimal" and "aggressive" censors from the original framework. In overprovisioned settings (proxies arriving at 250/step vs. 200 clients/step), even the null censor scenario outperforms either censor in equal-arrival settings. Over 90% of waiting users receive a proxy within 1 time step. The critical variable is not censor sophistication but proxy arrival rate relative to client demand—high proxy churn combined with high arrival rate defeats both enumeration strategies tested.

2026-fares-game §4, Fig 1, Fig 2, Table 1 evaluation

The host-profiling censor (passive traffic analysis: count connections per server, block those exceeding a threshold τ within a window w) blocks essentially all circumvention user traffic within 30 time steps for all classifier qualities tested (ρ_TP ∈ {0.9, 0.95, 0.99}), while causing far less collateral damage than zig-zag (never exceeding ~30% innocent server blocking). Snowflake resists this attack well: with w=3, τ=3, over 94.48% of users receive a proxy within 2 steps even with worst-classifier rules, and final unblocked server rates are 91.24–99.04%. The host profiling approach is feasible for passive censors who cannot enumerate the distribution channel.

2026-fares-game §5.2, Table 2, Table 3 detection

The zig-zag traffic analysis attack (confirmed supported in Geedge TSG leak) rapidly enumerates all static proxy pools. With ζ_watch ∈ {4, 6} steps and a best-quality classifier (ρ_TP=0.99, ρ_FP=0.001), almost total proxy enumeration and user blockage occurs well before step 300. Even ζ_watch=2 leaves ~50% of users blocked. Collateral damage is high across all settings when ζ_watch ≥ 4: eventually ~50% of innocent servers are also blocked. However, Snowflake-style ephemeral proxies resist zig-zag effectively: reachability remains above 95% after 360 steps because churn prevents the censor from expanding its known proxy set beyond agents' direct assignments.

2026-fares-game §5.1, Fig 3, Fig 4 detection

As of August 2026 in Fuzhou, Fujian, most censorship-resistant service providers are non-functional; a small number of providers using v2ray remain partially functional, while Tor Browser bridges and Snowflake are no longer usable.

2026-molotoves-wall-behind-wall Issue body deployment

Obscura's browser-to-browser (B-B) WebRTC connections produce DTLS ClientHello and ServerHello messages indistinguishable from genuine browser traffic: across 100 captured handshakes compared against Facebook Messenger, Google Meet, Discord, and a reference WebRTC app using the dfind tool, no unique identifiers were found in C-C connections, and the sole Firefox-specific fingerprint (ServerHello length 86 bytes, cipher TLS_AES_128_GCM_SHA256, extension field length 46 bytes) matches the default Firefox WebRTC profile — meaning blocking it would also block all legitimate Firefox WebRTC users.

2026-vilalonga-obscura-enabling-ephemeral §5.2 defense

A differential degradation attack (DDA) that selectively drops RTP packets carrying the last packet of a video frame — exploiting the fact that a single lost packet causes the entire encoded frame to be discarded — reduces Protozoa's covert throughput to single-digit KBps at 1920×1080 with 15% frame loss and at 426×240 with 50% frame loss, while maintaining acceptable video quality for legitimate WebRTC traffic.

2026-vilalonga-obscura-enabling-ephemeral §5.3 detection

Obscura proxies resist active probing by never exposing open ports or accepting incoming connections; combined with a large ephemeral volunteer pool (analogous to Snowflake's scale), the vast IP address space and rapid proxy rotation make exhaustive enumeration infeasible without causing sufficient collateral damage to deter the censor — consistent with the absence of observed blind-blocking campaigns against Snowflake.

2026-vilalonga-obscura-enabling-ephemeral §5.1 defense

Under baseline conditions (0% packet loss, no bandwidth constraint, 115 ms RTT), Obscura achieves average throughputs of 1.79 Mbps for Firefox-to-Firefox, 1.49 Mbps for Chrome-to-Chrome, and 1.32 Mbps for Pion-to-Pion connections; P-P connections collapse when the 2 Mbps target video bitrate exceeds the 1500 Kbps bandwidth constraint, while C-C connections remain usable at 10% packet loss with an average of 460 Kbps.

2026-vilalonga-obscura-enabling-ephemeral §4.3 evaluation

Authoritarian regimes blocked Snowflake primarily through DPI targeting fingerprints in Pion's DTLS handshake and TLS fingerprints in complementary WebRTC protocols, not through ML-based traffic analysis — confirming that cost-effective censors consistently favor simple, deterministic methods over computationally expensive classifiers.

2026-vilalonga-obscura-enabling-ephemeral §1 detection

A Russian user ran a self-built snowflake-proxy from inside the censored country using the 'random-and-mimic' fingerprint option, successfully serving Iranian, Turkmen, Russian, and German Tor users, demonstrating that the blocking is unidirectional (targeting client DTLS hellos) and that snowflake-broker and rendezvous domains (snowflake-broker.torproject.net, snowflake-01/02.torproject.net) remained accessible behind the .net SNI — only the DTLS data channel was filtered.

2026-wkrp-snowflake-targeted-dtls-filtering kad09 original report, Issue #422 comment evaluation

An experimental 'random-and-mimic' option in snowflake-proxy produced a DTLS ClientHello fingerprint distinct from any observed standard fingerprint and was not blocked by the Russian filter. The covert-dtls library under development by the Tor Anti-Censorship team systematically randomizes the DTLS ClientHello handshake to defeat JA3/JA4-based classification.

2026-wkrp-snowflake-targeted-dtls-filtering kad09 report + abstract team notes defense

PCAP analysis from inside Russia confirmed the filter is fingerprint-based, not IP-based: every failed DTLS connection shared the same JA3/JA4 fingerprint, while a single connection with a different JA3/JA4 fingerprint succeeded and sustained full-speed data transfer, eliminating the hypothesis that censors had enumerated the large proxy IP space.

2026-wkrp-snowflake-targeted-dtls-filtering kad09 original report, Issue #422 comment (Apr 5 2026) detection

Russia (TSPU/Roskomnadzor) began blocking Snowflake on 2026-03-30 by detecting DTLS ClientHello messages with specific JA3/JA4 fingerprints after a small delay. The block caused Snowflake to drop from ~100% connection success (measured from November 2025 through March 29) to near-total failure for standard proxies overnight.

2026-wkrp-snowflake-targeted-dtls-filtering Issue #603 opening comment (wkrp, Apr 6 2026) detection

Ceno Browser's decentralized peer-to-peer network grew from approximately 600 active peers on June 13 to nearly 8,000 by July 11, 2025 — a 13× increase in under 30 days — with some Ceno connections remaining online throughout the full blackout, indicating that P2P architectures without fixed enumerable infrastructure can survive centralized application-layer shutdowns.

2025-miaan-stealth-blackout Executive Summary — Resilient Response evaluation

In 24-hour live proxy deployments, covertDTLS mimicry had a 18.2% DTLS handshake failure rate (vs 12.5% baseline, 27.0% randomization, 25.8% Chrome webextension). Randomization generates ≈994 billion unique fingerprint permutations (cipher shuffling: 109,600; extension shuffling: 994,218,624,000), making blocklist-based fingerprinting infeasible, but at the cost of higher connection failures due to cipher mismatches. Mimicry of DTLS 1.2 was stable and effective; DTLS 1.3 mimicry is not yet achievable with the current Pion library.

2025-midtlien-fingerprint-resistant §4.2, Table 1, §5 evaluation

The DTLS ClientHello extensions field is the most prominent feature for fingerprinting Snowflake's Pion WebRTC stack. A passive DPI tool (dfind) validated against the MacMillan et al. dataset of 6,500 DTLS handshakes reliably identifies Pion-based implementations via unique extension byte patterns. Chrome randomized its extension list order starting with version 129.0.6668.58 (September 2024), yielding 6! = 720 unique permutations and hardening it against deterministic matching. Firefox adopted DTLS 1.3 by default from version 127 (May 2024), which changes the extension structure entirely and renders DTLS 1.2 mimicry obsolete for Firefox traffic.

2025-midtlien-fingerprint-resistant §3, §4.1 detection

Firefox adopted DTLS 1.3 by default for WebRTC in May 2024 (version 127); Chrome has implemented DTLS 1.3 in BoringSSL but not yet enabled it by default. DTLS 1.3's Encrypted Client Hello (ECH) extension would encrypt extension lists and make passive field-based fingerprinting of those extensions obsolete — but censors may choose to block DTLS 1.3 ECH unless browsers adopt it widely enough that blocking causes unacceptable collateral damage. The Pion library (used by Snowflake standalone proxies) has no concrete roadmap for DTLS 1.3 support, creating a growing gap.

2025-midtlien-fingerprint-resistant §4.1, §5, §7 defense

Iranian censors actively detected and blocked circumvention proxies in real time during the June 2025 shutdown: MTProto proxies, v2ray tunnels (VLESS and VMESS variants), and Tor bridges using both Snowflake and obfs4 all experienced mixed or degraded success as proxies were identified and blocked.

2025-pirooz-gthb-internet-completely-blocked Abstract / community testing thread detection

The proposed system adopts the turbo tunnel architecture to provide a reliability layer over lossy TURN relay paths and to allow traffic reassembly at a single bridge across multiple TURN proxies. Three encapsulation modes are specified: direct application data inside TURN messages, DTLS datagrams via WebRTC data channels, and video frames inside WebRTC media streams — the latter two mimicking the encapsulation strategies of existing WebRTC circumvention systems such as Snowflake and TorKameleon.

2025-vilalonga-extended §2 System Design defense

Snowflake's sustained operation in heavily censored regions demonstrates that WebRTC must remain accessible to users, which in turn requires that TURN servers remain unblocked to support NAT traversal for peer-to-peer WebRTC connections. This transitive unblockability makes TURN service providers viable rendezvous channels for the Bridge Distribution Problem.

2025-vilalonga-extended §3.2 Bridge Distribution Problem defense

TURN servers used by major applications such as Facebook Messenger for media relay are hypothesized to be less likely blocked in censored regions due to collateral damage to legitimate WebRTC traffic. Providers like Cloudflare, Metered Video, and ExpressTURN supply geographically distributed TURN infrastructure that can be used without any special configuration by a censorship evasion system.

2025-vilalonga-extended §1 Introduction & Background defense

The system targets a threat model where the censor performs passive DPI to fingerprint and block the client-to-TURN-proxy channel, and also conducts active enumeration attacks to discover and block proxy endpoints. The paper explicitly notes that traffic splitting may introduce distinct fingerprints of its own that require empirical evaluation — acknowledging that multi-path approaches are not fingerprint-free.

2025-vilalonga-extended §3.1 Threat Model defense

Traffic splitting across N TURN proxies (1 ≤ N ≤ M) is hypothesized to resist active probing because each TURN server responds to probing requests identically to a regular TURN server, providing no distinguishing signal. Additionally, proxy ephemerality combined with splitting allows on-the-fly migration to new proxies when existing ones are blocked, maintaining connectivity even under partial blocking.

2025-vilalonga-extended §3.3 Censorship Evasion defense

Snowflake has been deployed in Tor Browser and Orbot for several years and served as a significant circumvention tool during the Russia 2021 network disruptions and Iran 2022 protests. The paper documents a history of deployment and blocking attempts, providing empirical evidence that the ephemeral WebRTC proxy design has sustained availability under real censor pressure across multiple high-profile events.

2024-bocovich-snowflake §1, §6 deployment

Snowflake's blocking resistance rests on a large, constantly changing pool of volunteer WebRTC proxies implemented as lightweight JavaScript browser extensions or web pages. Because the proxy population is in constant churn and new addresses appear faster than censors can enumerate and block them, IP-list blocking is structurally ineffective. The system is designed so that when an in-use proxy goes offline, the client seamlessly migrates to another with no disruption to upper network layers.

2024-bocovich-snowflake §1, §2 defense

Snowflake proxies are simple enough to run as JavaScript inside a web page or browser extension, making them far cheaper to operate than a traditional VPN or proxy server. This low operational cost enables a large volunteer pool (orders of magnitude more participants than server-hosted bridge networks), which is the structural property that makes IP enumeration hard for censors.

2024-bocovich-snowflake §2, §3 defense

SpotProxy adapts both WireGuard and Snowflake to work with its active proxy migration mechanism, demonstrating that the approach is protocol-agnostic. The active migration mechanism allows clients to move between proxies seamlessly without performance degradation or connection disruption when a proxy is replaced — a requirement for any high-churn proxy infrastructure.

2024-kon-spotproxy §3, §5 defense

Censors employing deep learning can use DTLS connection duration as a precise identifier to classify and block Snowflake traffic. The paper proposes switching PT connections after a variable time limit as a countermeasure to prevent duration-based classification.

2024-lorimer-extended §4.3 detection

Initial attempts to split Snowflake traffic naively across multiple WebRTC proxies produced either no improvement in performance or a net negative effect. The authors attribute this to the wide variance in proxy network stability and bandwidth and flag it as an open problem requiring more advanced splitting algorithms.

2024-lorimer-extended Appendix A evaluation

Reusing the same 64-bit client ID across rendezvous attempts caused approximately 3-minute delays in failure scenarios because the SQS queue deletion API can take up to 60 seconds to complete, forcing subsequent attempts to wait for the previous outgoing queue's deletion before a new queue with the same ID can be created. The fix generates a fresh random 64-bit client ID per attempt, eliminating the dependency on prior-attempt cleanup.

2024-pu-exploring §4.2 defense

A single shared bidirectional SQS queue was rejected for Snowflake rendezvous because SQS provides no mechanism to direct messages to a specific consumer — all polling clients would receive all other clients' messages, creating a privacy violation. The adopted design uses one shared incoming queue (broker-read-only) plus per-client temporary outgoing queues identified by randomly generated 64-bit IDs, with the broker periodically deleting queues idle for more than a configurable number of minutes.

2024-pu-exploring §3.1 defense

Amazon SQS routes client traffic through a single fixed HTTPS endpoint (https://sqs.us-east-1.amazonaws.com), making it infeasible for a censor to distinguish circumvention-bound SQS traffic from legitimate AWS service traffic; blocking this signaling channel would require blocking all Amazon SQS, imposing significant collateral damage on businesses and developers.

2024-pu-exploring §2.2 defense

AWS credentials distributed publicly to enable client access to the SQS API were flagged by GitHub's automated secret-scanning and AWS Support requested their deletion, even though the credentials carried intentionally limited permissions. The operational workaround adopted — base64-encoding credentials before public distribution — bypasses automated scanning but provides no real security.

2024-pu-exploring §4.2 deployment

The SQS rendezvous method was deployed in Snowflake v2.9.0 / Tor Browser 13.0.10 (February 2024) and as of 2024-06-22 had served over 14,808 client connections from over 20 countries including Iran, China, the United States, and Russia, while remaining within the AWS Free Tier limit of 1 million requests per month and incurring no monetary cost.

2024-pu-exploring §4 deployment

Using Google Pub/Sub as a rendezvous channel adds 7.17 seconds of bootstrapping overhead vs. a 1.32-second direct baseline when establishing a TorKameleon WebRTC bridge connection (total: 8.49s vs. 1.32s). The dominant bottleneck is subscription creation time (5.23s), not the message exchange itself (3.26s), averaged across 10 samples with 113 ms cross-Atlantic latency.

2024-vilalonga-looking §4.2, Table 1 evaluation

CNN-based deep learning reduces obfs4 false positive rate by an order of magnitude versus the best decision tree (FPR 2.9×10⁻³ vs. 3×10⁻²) while maintaining 100% recall, and achieves near-perfect Snowflake data-flow detection (Precλ=1k = 0.95, Fλ=1k = 0.97). However, at realistic base rates λ > 10⁶ all CNN classifiers still yield near-zero precision, leaving per-flow deep learning alone insufficient for nation-state-scale deployment.

2024-wails-precisely §V-C, Table IV, Figure 5 detection

The paper identifies that circumvention systems relying on long-lived, consistent proxy servers are fundamentally vulnerable to host-based temporal detection regardless of per-flow obfuscation quality, and recommends adversarial examples, ephemeral obfuscation servers, and programmable or polymorphic protocols as countermeasures. Snowflake's volunteer-browser proxy architecture—where proxies are ephemeral and addresses are not reused—is highlighted as inherently more resistant to host-based classification than static bridge designs like obfs4.

2024-wails-precisely §I, §VI discussion, §VII defense

Replacement-based covert channels that substitute genuine media streams with ciphertext (Protozoa replacing WebRTC video, Balboa replacing audio) are immediately detectable when the censor controls or has plaintext access to the protocol gateway — for example, a WebRTC relay that decrypts and validates incoming media. Censors can also systematically suppress these channels by selectively degrading or blocking encrypted traffic for which they have no decryption trapdoor.

2023-ding-discop §I detection

Operating system defaults create two additional scaling ceilings beyond CPU: (1) the default file descriptor limit is insufficient above ~64,000 simultaneous connections, requiring LimitNOFILE=1048576 (1 million) in the systemd service; and (2) Linux's conntrack default of 262,144 tracked connections was approached during peak hours for the Snowflake bridge, necessitating doubling the table to 524,288 via sysctl net.netfilter.nf_conntrack_max.

2023-fifield-running §4 deployment

A single Tor process is limited to one CPU core, creating a performance ceiling that manifests at approximately 6,000 simultaneous users and 10 MB/s of Tor bandwidth. The solution is running multiple Tor processes (starting with 4, scaling to 12) sharing the same long-term identity keys, mediated by an HAProxy load balancer, which enabled a Snowflake bridge to scale from 2,000 to ~100,000 simultaneous users between December 2021 and February 2023.

2023-fifield-running §3 deployment

Protozoa's encoded media tunneling embeds covert IP packets directly into VP8-encoded frame bitstream partitions (EFBP) after lossy compression, rather than into raw pixel data. Because SRTP uses a stream cipher that preserves plaintext size, overwriting EFBP bits leaves encrypted packet sizes identical to legitimate sessions, and the covert channel achieves 98.8% utilization of available frame space at an average throughput of 1422 Kbps—a 3× improvement over Facet and roughly three orders of magnitude over DeltaShaper's 7 Kbps maximum.

2020-barradas-poking §4.4, §6.2 defense

Protozoa's encoded media tunneling achieves an AUC of 0.59 against a state-of-the-art ML traffic classifier using packet-size and inter-arrival-time features—near the 0.5 random-guessing baseline—compared to >99% detection rates for prior tools such as Facet and DeltaShaper. To block 80% of Protozoa flows (TPR=0.8), a censor would erroneously flag approximately 60% of legitimate WebRTC flows (FPR=0.6). This resistance holds across trace durations from 10–60 seconds (AUC range 0.56–0.61) and across RTT, bandwidth, and packet-loss variations.

2020-barradas-poking §6.2, Table 1, Figure 8 evaluation

Protozoa's covert channel throughput degrades gracefully under bandwidth constraints but remains usable for common applications: average throughput is 975 Kbps at 1500 Kbps cap, 460 Kbps at 750 Kbps, and 91 Kbps at 250 Kbps. Under 2% and 5% packet loss the channel sustains 1130 Kbps and 360 Kbps, respectively, while 10% loss (near WebRTC tear-down threshold) still yields 160 Kbps without breaking the connection. Traffic analysis resistance is preserved across all these conditions, with AUC peaking at 0.65.

2020-barradas-poking §6.3, Figures 9–10 evaluation

Protozoa successfully bypassed censorship in China, Russia, and India using whereby.com as a carrier. Despite several WebRTC services being blocked in China (appr.tc, discordapp.com, hangouts.google.com, messenger.com), at least seven alternatives remained reachable (aws.amazon.com/chime, coderpad.io, gotomeeting.com, slack.com, whereby.com, and others), ensuring carrier availability. Covert sessions over the alternative services coderpad.io and appr.tc achieved AUCs of 0.58 and 0.60, respectively, and average throughput of 1388–1420 Kbps.

2020-barradas-poking §7.2, Table 3 evaluation

Protozoa uses the economic and social indispensability of popular WebRTC conferencing services as a censorship deterrent: blocking all WebRTC traffic imposes prohibitive collateral damage on legitimate commerce and communication. This 'parasitism' strategy means the circumvention tool inherits the blocking immunity of the carrier without requiring any protocol mimicry at the network level. Protozoa requires only one reachable WebRTC service to function, and Table 3 confirms at least five services remained unblocked in China during testing.

2020-barradas-poking §3, §7.2 defense

When a censor controls the WebRTC signaling plane, it can mount MITM attacks against CRON's vanilla covert encoding because the encoding 'fully replaces the video payload with an apparently random covert data signal that results in a scrambled video image at the receiver's endpoint.' By replaying the captured video through a WebRTC gateway, the censor obtains direct visual evidence of payload manipulation.

2020-barradas-towards §4.2 detection

CRON restricts multi-hop covert circuits (N≥1 relays) to delay-tolerant traffic only, because establishing multiple simultaneous WebRTC video calls is 'highly atypical in normal user profiles' and would trigger S1 behavioral anomaly detection. Real-time interactive tunneling is limited to direct circuits (N=0) within pre-existing calls, and active mode introduces only bounded variability in call times and frequency to stay within plausible user-profile ranges.

2020-barradas-towards §4.1 defense

Protozoa creates a ≈1.4 Mbps covert channel over WebRTC by replacing encoded video frames with covert payload while preserving SRTP packet size and timing properties, making Protozoa flows 'hardly distinguishable from unmodified WebRTC streams using existing ML-based traffic classifiers.' Since all unencrypted packet fields remain intact, DPI cannot detect the tunnel either.

2020-barradas-towards §2 defense

CRON's stego circuits defend against adversary-controlled WebRTC services by embedding covert data into encoded video frames at the compressed data domain using video steganography algorithms, maintaining the visual characteristics of the video feed rather than replacing it entirely. Endpoint authentication uses public-key encryption with keys exchanged out-of-band, preventing MITM key substitution through the censor-controlled signaling server.

2020-barradas-towards §4.2 defense

Even when individual WebRTC flows pass traffic analysis, a censor can identify CRON users via three long-term statistical attack types: S1 (simultaneous video calls, atypical for normal users), S2 (sudden connections to previously unknown parties), and S3 (calls at anomalous times, frequencies, or durations). Relay nodes in multi-hop circuits are particularly exposed via S1 because conducting multiple simultaneous video calls is highly atypical in normal user profiles.

2020-barradas-towards §4.1 detection

Turbo Tunnel inserts an interior session/reliability protocol (KCP or QUIC) between the obfuscation layer and user streams, decoupling end-to-end session state from any single transport connection. A session survives TCP termination, proxy rotation, or unreliable carriers by retransmitting lost packets over a new connection bearing the same session identifier. The pattern was implemented in obfs4, meek, and Snowflake, with Turbo Tunnel–enabled Snowflake shipping in Tor Browser alpha releases 9.5a13 (desktop) and 10.0a1 (Android).

2020-fifield-turbo §1–§2 defense

Snowflake exclusively uses WebRTC data channels (on-wire protocol: DTLS), whereas the majority of WebRTC applications use media channels (DTLS-SRTP or SRTP/SDES); a censor can therefore block Snowflake by filtering data-channel flows alone without blocking WebRTC media applications, incurring minimal collateral damage and reducing the overblocking deterrent.

2016-fifield-fingerprintability §6 detection

The authors extend Houmansadr et al.'s 'parrot is dead' argument to WebRTC: because WebRTC is a large multi-protocol framework, superficial mimicry that fails to replicate exact DTLS version, cipher suite ordering, certificate common name ('WebRTC'), 30-day validity period, STUN server selection, and ICE packet sequence leaves detectable residual distinguishers, making deep fingerprint conformance especially hard for standalone non-browser implementations such as Snowflake's client.

2016-fifield-fingerprintability §3, §4.6 defense

Among the five WebRTC applications analyzed (Google Hangouts, Facebook Messenger, OpenTokRTC, Sharefest, Snowflake), Snowflake is uniquely identifiable by its use of DTLSv1.2 (all others use DTLSv1.0), its 17 offered cipher suites, and its exclusive selection of TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256—a cipher suite not chosen by any other application in the study.

2016-fifield-fingerprintability §4.5, §4.6 detection

STUN and TURN packets carry a SOFTWARE attribute that explicitly names the server implementation (e.g., 'Citrix-3.2.5.1 Marshal West' for OpenTokRTC), and the choice of STUN servers, forced-TURN usage, and STUN message-type sequence (Binding-only vs. Allocate+CreatePermission vs. send-indication) differ across applications, providing a passive censor with reliable application-level fingerprints orthogonal to the DTLS layer.

2016-fifield-fingerprintability §2, §4.1–§4.5 detection

A DTLS fingerprinting script run on one full day of network traffic at Lawrence Berkeley National Laboratory found only 7 DTLS handshakes with 3 unique client fingerprints and 3 unique server fingerprints, suggesting there may not be enough naturally occurring WebRTC traffic to provide meaningful cover for a WebRTC-based circumvention system.

2016-fifield-fingerprintability §5 evaluation