DEFENSES
meek Meek (HTTP-based pluggable transport)
6 papers on file
- 2025-miaan-stealth-blackout Iran's Stealth Blackout: A Multi-stakeholder Analysis of the June 2025 Internet Shutdown
- 2015-frolov-the-use-of-tls The use of TLS in censorship circumvention
- 2019-sheffey-improving Improving Meek With Adversarial Techniques
- 2015-fifield-blocking-resistant Blocking-resistant communication through domain fronting
- 2012-fifield-evading Evading Censorship with Browser-Based Proxies
- 2011-mccoy-proximax Proximax: A Measurement Based System for Proxies Dissemination
26 findings tagged here
-
A machine-checked EasyCrypt proof demonstrates that a conjunctive SNI + traffic-profile adversary achieves a true positive rate of 1.0 against meek, with a false positive rate bounded by Pr[Game0(MeekEnc).main()=true] ≤ (1/10000) × (1/1000) ≈ 10⁻⁷, under the assumption that meek traffic follows a normal distribution centered at 512 bytes and background traffic a Poisson-like distribution centered at 1024 bytes. The proof is fully machine-checked in EasyCrypt.
-
UP channels based on free third-party content hosting (video, audio, images, ML models) provide no-cost scalability: steganographic videos once uploaded are free to distribute to arbitrarily many users, and the channel sustains adversarial financial denial-of-service attacks without incurring operator costs. This contrasts with meek, SQS, AMPCache, and Skyhook, which face financial DoS risk because adversaries can drive up hosting costs by using those channels as intended.
-
Among surveyed channels, Skyhook, PushRSS, SQS, AMPCache, and Meek satisfy all three UP channel properties (unidirectional, no client auth, higher bandwidth); CloudTransport and Raven do not because they require authenticated user accounts; Tor's email- and Telegram-based bridge distribution also fails the no-auth requirement. The analysis was prompted in part by the 2022 GFW entropy-based blocking event, which required software updates to be pushed to users before fully-encrypted protocols could resume functioning.
-
The paper documents that bridge distribution across major circumvention tools (Tor Browser's Moat, Snowflake) relies entirely on domain fronting (meek) for automated, user-friendly bootstrapping. This concentration means a censor that defeats domain fronting — or that pressures CDN providers to stop offering it — removes essentially all automated bridge-discovery pathways simultaneously, leaving only manual out-of-band methods (email/Telegram accounts) that require many user interactions.
-
Raceboat formalizes a decomposition of application-protocol-tunneling channels into three reusable components (Transport, User Model, Encoding) and a channel manager that supports mixing unidirectional channels. By composing seven different channels from these modular components (including email, AWS S3, and Redis variants), the paper demonstrates that the current ad-hoc one-protocol-one-implementation model wastes significant re-implementation effort: the same transport or encoding logic is duplicated across Snowflake, meek, CloudTransport, and others.
-
The paper argues that a greater diversity of signaling channels reduces the censor's leverage: when many independent services (cloud storage, email, push notifications, domain fronting) can each bootstrap a circumvention connection, a censor must block all of them to prevent access, and the collateral damage of blocking each may deter action. Skyhook specifically targets cloud storage as an additional independent pathway alongside existing channels like meek, Raven (email), and PushRSS.
-
Domain fronting is undermined when CDN front-ends are located within the censor's jurisdiction because the censor can coerce the CDN provider to disable domain fronting on those front-ends. Russia coerced Google, Amazon, and Microsoft to halt Telegram's use of domain fronting; the paper's measurements confirm that CDN front-ends for popular services (YouTube, Facebook, Instagram) are hosted within all five tested countries.
-
Simultaneous upload and download of a 10 MB file took 10.6 s over TCP-encapsulated QUIC, 23.3 s over traditional meek, and 34.9 s over meek with encapsulated QUIC (Table 1), showing that naively adding a QUIC session layer to meek degraded throughput by approximately 50% relative to unmodified meek. Performance was sensitive to HTTP body size limits and request-thread count, but the root cause remained uncertain.
-
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).
-
Frolov and Wustrow show that every major TLS-based circumvention tool (Tor Browser, Lantern, OpenVPN, Psiphon, etc.) produces a TLS ClientHello fingerprint that is statistically distinguishable from real Chrome or Firefox: differences include cipher-suite ordering, extension set, extension ordering, ALPN values, and curve preferences. A passive observer with a classifier over ClientHello fields can identify the tool with high precision without decrypting any traffic.
-
An adaptive censor that retrains classifiers on both unmodified and GAN-transformed Meek traffic ('informed NN') partially recovers detection capability: informed NN achieves a PR-AUC of 0.440 against modified traffic versus 0.309 for the naive NN, and achieves FPR of 0.667 versus 1.000 for the naive NN. However, the informed NN suffers from catastrophic interference and performs worse on FPR than the naive classifier on unmodified data (0.545 vs. 0.002).
-
A GAN-based adversarial transformer applied to Meek traffic signatures increases mean classifier FPR from 0.183 to 0.834 and decreases mean area under the precision-recall curve (PR-AUC) from 0.990 to 0.414 across naive neural network, informed neural network, and CART decision tree classifiers evaluated on three geographically distinct datasets (residential, university, AWS).
-
The paper identifies that Meek traffic is compared against average HTTPS traffic across all domains rather than against traffic specific to the CDN fronting host (e.g., ajax.aspnetcdn.com for meek-azure), meaning a transformed signature that mimics generic HTTPS may still appear anomalous relative to expected traffic to that specific CDN host. This dataset construction limitation means real-world GAN-guided shaping must target host-specific traffic baselines, not population-wide HTTPS baselines.
-
Prior ML classifiers achieve near-perfect detection of unmodified Meek traffic using side-channel features: Wang et al. attain a false positive rate (FPR) as low as 0.0002 with a CART decision tree, Yao et al. achieve 99.98% accuracy with a hidden Markov model, and Nasr et al. deanonymize Meek flows with FPR of 0.0005 using a neural network. The distinguishing features are TCP payload size distributions (Meek concentrates 60–70 byte payloads) and inter-arrival time distributions (higher latency).
-
Incorporating perturbation loss — the mean absolute difference between original and transformed traffic signatures — into the GAN's training objective constrains the transformer to make minimal modifications, reducing the implementation overhead a real-time traffic shaper would require. The perturbation loss is weighted at 10× relative to classification losses, enforcing sparse modifications while still fooling the discriminator.
-
Meek over Azure CDN successfully established Tor circuits from China in all tests; meek over Amazon was inconsistent and often failed mid-circuit. Meek requires TLS on the bridge — without it the GFW blocks the bridge within minutes and purges it from the blacklist, suggesting a separate meek-specific detection and blocklist is maintained.
-
In the heavily censored environment (E3), all successful connections used meek domain-fronting bridges (meek-amazon: 11 participants, meek-google: 9, meek-azure: 3); not a single participant successfully connected using flashproxy, fte, fte-ipv6, obfs4, or scramblesuit, despite all being available as built-in options.
-
The authors recommend 'smart automation' for bridge selection: the client first connects via a hard-to-censor bridge, then contacts a central Tor server over that Tor connection to identify the best available bridge for the user's location and network conditions, then reconnects using that bridge — eliminating the manual trial-and-error that caused 79% of attempts to fail. This is contrasted with 'naive automation' (sequential blind retry) which avoids UI friction but wastes time on non-working bridges.
-
A redesigned Tor Launcher interface significantly increased success rates (Pearson χ² = 2.808, p < 0.047) and reduced median connection time in E3 from 40:08 to 20:25 (Mann–Whitney Z = −1.84, p < 0.0328, r = 0.172); configuration time also dropped significantly (Z = −3.28, p < 0.0005, r = 0.307). Changes included eliminating yes/no bridge and proxy question screens, adding auto-detection for proxies, consolidating options, and surfacing meek bridges as a fallback recommendation.
-
Measured packet loss rates under GFW censorship (Feb–Apr 2017, client at Tsinghua University/CERNET): Tor with meek obfuscation suffers 4.4% average PLR; Shadowsocks (AES-256-CFB) suffers 0.77% PLR; native VPN (PPTP/L2TP) and OpenVPN both achieve ~0.21% PLR. For comparison, the same tools accessed from a US vantage point show PLR below 0.1%, confirming the excess loss is GFW-induced. The GFW's DPI and active probing techniques specifically target Tor and Shadowsocks protocol signatures.
-
CDNBrowsing of full-CDN content imposes near-zero operational cost on circumvention operators because all bandwidth is paid by the censored content publisher via their CDN contract; dynamic mirrors for partial-CDN sites impose negligible additional load compared to proxy-based systems — measured traffic relayed by CDNReaper dynamic mirrors versus the meek pluggable transport for sample sites was nearly negligible, while meek has cost Tor $26,536 total ($2,479/month at the time of measurement) despite a 1.5–3 MB/s per-user bandwidth cap and a discounted research grant rate.
-
Domain fronting exploits the fact that major CDN providers (Google, Amazon CloudFront, Akamai, Microsoft Azure) terminate TLS at the edge before inspecting the Host header, so the SNI visible to a censor names a permitted CDN domain (e.g., www.google.com) while the inner HTTP Host header routes the request to a blocked destination. Blocking the fronted service requires blocking the entire CDN, creating collateral damage that most censors are unwilling to accept for major providers.
-
The meek pluggable transport, implementing domain fronting over HTTPS, achieved median download throughput of roughly 1–2 Mbps in controlled tests from censored regions (China, Iran), confirming that CDN-fronted tunnels are viable for real users at consumer broadband speeds. Latency overhead compared to direct connections was measurable (tens of milliseconds per round-trip through the CDN edge) but acceptable for browsing workloads.
-
CART decision-tree classifiers trained on entropy-based and packet-header features detect all five Tor pluggable transports (obfsproxy3/4, FTE, meek-amazon, meek-google) with average PR-AUC=0.987, TPR=0.986, and FPR=0.003 on synthetic traces. On 14 million real campus flows the highest per-obfuscator FPR is 0.65%, and meek-google yields only 842 false positives across all three datasets. However, cross-environment portability is poor: classifiers trained on an Ubuntu/campus setup and tested on a Windows/home network achieve true-positive rates as low as 52% with false-positive rates reaching 12%.
-
If a large site such as Google or Wikipedia scrambled all served content using a publicly known de-scrambling algorithm, the censor faces a strict all-or-nothing blocking decision: it cannot selectively filter banned scrambled content without blocking the entire site, since scrambled legitimate and banned content are computationally indistinguishable prior to running S⁻¹. This property scales the political cost of blocking proportionally to the size of the co-scrambling platform.
-
By 2009, the top 150 autonomous systems carried approximately 50% of all Internet traffic globally, up from roughly 30% in 2007. Akamai alone claimed approximately 20% of all web traffic, and the proposed Level 3 / Global Crossing merger would have covered over half the world's IP addresses.