The original Slitheen appended covert upstream data directly to overt HTTP requests, significantly changing upstream traffic patterns and enabling censor identification even when traffic is encrypted. This upstream traffic analysis vulnerability—absent from Slitheen's original threat model—is the primary weakness Slitheen++ addresses.

Slitheen++ achieves a median covert site loading time of 7 seconds in the naive setup, rising to 8 seconds with crawling and 13 seconds with a 1-second thinking-time (TT) delay. The Baseline-to-Covert factor ranges from 3.7–8.5 without TT and from 7.6–21.4 when crawling and 1-second TT are combined, reflecting the fundamental tradeoff between stealth overt behavior and covert throughput.

§5 (Figure 1, Figure 2) evaluation

Slitheen++ embeds covert upstream data by applying HTTP/2-like header field compression to overt HTTP requests, using the recovered space for covert data placement. This ensures that neither timing information nor observable changes to packet sizes or delays can reveal decoy routing use to an omni-scientist passive censor. GZIP compression was explicitly avoided to prevent the CRIME side-channel attack.

§4 defense

Slitheen++'s relay station introduces minimal overt forwarding overhead: 95% of setups saw downstream per-packet delays between 1 ms and a maximum of 4 ms, with on average only 0.0029% of downstream packets affected (peak 0.006% in any single scenario). Upstream delays were similarly low except for a single outlier near 60 ms caused by thread contention during crawling-induced relay load spikes.

§5 (Table 1) evaluation

A censor can identify Slitheen relay connections by observing that all packets in a suspected overt flow arrive in strict order while flows from the same source naturally exhibit out-of-order delivery: the relay station's traffic-server component reorders TCP segments to enable TLS record decryption, creating a statistically anomalous per-connection ordering pattern. The reordering buffer also increases per-packet round-trip times, providing a secondary timing signal.

§4, §6 detection

A three-stage detection pipeline exploiting the "dual-role" behavioral fingerprint of single-IP circumvention relays achieved 23.2% recall (96/414 ground-truth relays) with a 0.18% false-positive rate against 97,651 benign TLS servers, for an overall accuracy of 99.5%. The ground-truth set covered OpenVPN, WireGuard, and SOCKS relays identified in a 17 TB single-day backbone trace (WIDE Project, April 9, 2025).

2026-almutairi-server §3.4, Table 1 traffic-shapedpiflow-correlation

The paper identifies a fundamental architectural vulnerability in single-IP circumvention designs: a relay must generate new observable flows (via DNS or TLS SNI) to reach end services after receiving client connections, creating a detectable server-and-client behavioral contrast. A relay accessing user-facing domains (news, social media) scores high on a Relay Suspicion Score (w=0.9) versus infrastructure domains (w=0.1). The paper argues this host-level signal is censorship-invariant and cannot be concealed by link obfuscation.

2026-almutairi-server §2.4, §4 traffic-shapedpisni-blocking

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 dpitraffic-shape

Multi-censor simulations show that single-censor-optimized distribution strategies perform suboptimally in realistic multi-region deployments. When two networks have different censor strategies (e.g., one optimal, one zig-zag), the distributor cannot detect that a proxy is blocked until all censors have blocked it; this leaves clients without reachable proxies despite the proxy appearing "available" from the distributor's view. The authors conclude that "single-censor evaluation does not accurately predict more realistic deployment performance." A zig-zag censor in one region with 0.25 weight caused 44.4% collateral damage while reducing proxy lifetime to a median of 4 steps.

2026-fares-game §6, Table 4 traffic-shapeflow-correlation

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 traffic-shapeflow-correlation

WebSocket, required by HTTPT and WebTunnel to establish covert channels inside TLS connections, had an adoption rate as low as 6.3% of websites in 2021, sharply limiting the pool of volunteer websites that can act as proxies for these tools. By contrast, Huma's traffic replacement scheme embeds covert data in standard HTTP leaf objects (images, scripts, CSS), requiring only that the DW serve HTTP content — a near-universal property.

2026-kamali-huma §II-C dpitraffic-shape