DEFENSES
vmess VMess (V2Ray)
9 papers on file
- 2025-iran-shutdown-measurement Characterizing Iran's Phased National Internet Shutdown in 2025: A Progressive and Distributed Action
- 2026-anon-github-2026-6-dns GitHub无法访问？2026年最新6种解决方法（含DNS修改与加速工具） | 二毛
- 2025-aryapour-stealth-blackout Iran's Stealth Internet Blackout: A New Model of Censorship
- 2025-miaan-stealth-blackout Iran's Stealth Blackout: A Multi-stakeholder Analysis of the June 2025 Internet Shutdown
- 2025-mixon-baca-hidden Hidden Links: Analyzing Secret Families of VPN Apps
- 2024-xue-tspu-russia Tspu: Russia's decentralized censorship system
- 2023-wu-fully-encrypted-detect How the Great Firewall of China detects and blocks fully encrypted traffic
- 2022-blocking-tls-circumvention Large scale blocking of TLS-based censorship circumvention tools in China
- 2020-v2ray-weaknesses Summary on Recently Discovered V2Ray Weaknesses
17 findings tagged here
-
Chinese users treat full proxy/VPN (Shadowsocks, V2Ray/Clash, commercial VPNs) as the '终极大杀器' (ultimate solution) for bypassing GitHub DNS poisoning, implying that lighter-weight DNS-only fixes fail in some network environments where the censor adds firewall-layer blocking beyond DNS.
-
Rule-based proxy tools (Clash, Shadowsocks, V2Ray) are documented as the most reliable solution for accessing GitHub from China, with split-tunneling rules routing only GitHub traffic through the proxy while keeping domestic traffic on the direct path. Git command-line tools require explicit proxy configuration (git config --global http.proxy http://127.0.0.1:7890) to route clone/push operations, as they do not inherit system proxy settings automatically.
-
Under April 2026 enforcement pressure, surviving VPN resellers converged on three strategies: raising prices to cover higher infrastructure costs, switching from transit to direct-connect (higher latency, worse peak-hour performance), or deploying proprietary protocols with dedicated clients — the last option breaking compatibility with standard Clash and Shadowrocket clients and fragmenting the interoperable ecosystem.
-
Beyond business-filing cross-references, the paper introduces a method of linking VPN provider families by showing they share VPN server cryptographic credentials (Shadowsocks passwords, server TLS fingerprints) across distinct app identities. This extends prior ownership-attribution methods that relied solely on corporate registry data and code similarity, adding shared live infrastructure as a linkage signal that is harder for operators to obscure.
-
Shaperd introduces a constraint-agnostic traffic shaping system that operates on both packet content and timing in real time, designed for drop-in integration with any existing FEP. The system uses a four-component constraint definition (function, value, comparison operator, target packets) capable of expressing any rule based on a computable deterministic function over packet contents.
-
Per-flow RTTdiff detection rates are only ~20% because the majority of proxy flows connect to CDN-cached content (Cloudflare, Google, Fastly) that sits within 5ms of the proxy, suppressing the discrepancy. However, aggregating across flows per website visit yields detection rates exceeding 70%—and from the abstract, approximately 80% of top-5K domains generate at least one detectable flow—with half of those detections made within the first 60 packets. This means an adversary can reliably expose client and proxy IPs after just a few website visits.
-
Proxy users who resolve DNS locally (at the client) are approximately twice as susceptible to RTTdiff fingerprinting compared to users who resolve DNS at the proxy, across all tested client/proxy location combinations. Local DNS returns IPs optimally reachable from the client's region, which may be geographically distant from the proxy, increasing the proxy-to-server path distance and thus the RTTdiff discrepancy.
-
Cross-layer RTT discrepancy (RTTdiff) is a protocol-agnostic fingerprint that exploits an inherent architectural property of all proxy setups: transport-layer sessions terminate at the proxy while application-layer sessions remain end-to-end. Evaluation across 10 proxy protocols—including VMess, Shadowsocks, VLESS, Trojan, XTLS-Vision, and obfs4-wrapped SOCKS—shows near-identical detection rates for all except obfs4, confirming the fingerprint is not tied to any specific obfuscation scheme. At FPR=0.01, per-website detection rates exceed 70% across all tested client and proxy location combinations.
-
Obfuscated proxy traffic (including Shadowsocks, VMess, VLESS, Trojan, obfs4, and REALITY) can be reliably fingerprinted by detecting encapsulated TLS handshakes — the inner TLS ClientHello that appears inside an outer encrypted tunnel. This fingerprint is protocol-agnostic: any proxy that wraps TLS-bearing application traffic will produce it. The authors deployed a similarity-based classifier within a mid-size ISP serving over one million users and demonstrated detection with minimal collateral damage.
-
While stream multiplexing reduces the visibility of encapsulated TLS handshakes by merging inner connections, the paper cautions that multiplexing plus random padding alone is "inherently limited" as a long-term countermeasure. Censors can adapt by monitoring burst sizes and round-trip counts at the outer-connection level, which remain correlated with the number of inner TLS sessions regardless of padding.
-
VMess's encrypted command block used a non-keyed hash over variable-length fields in a MAC-then-encrypt construction where the receiver cannot locate the hash without first parsing the protected data, enabling an active distinguishing attack: by replaying an authentic request 16 times with the padding-length field P set to 0000–1111, an attacker observes that a VMess server reads exactly P+N+4 bytes before disconnecting, with max and min byte counts differing by exactly 15 with every intermediate value present. V2Ray mitigated this in v4.23.4 by disconnecting after a timeout rather than after receiving a full command block.
-
The GFW's fully-encrypted detector (deployed Nov 2021) operates by exempting likely-benign traffic and blocking the rest. Five inferred exemption rules applied to the first TCP payload (pkt): Ex1 — popcount(pkt)/len(pkt) ≤ 3.4 or ≥ 4.6 (bits/byte); Ex2 — first 6+ bytes are printable ASCII [0x20–0x7e]; Ex3 — more than 50% of bytes are printable ASCII; Ex4 — more than 20 contiguous printable ASCII bytes; Ex5 — first bytes match TLS or HTTP fingerprint. Traffic failing all five exemptions is blocked. Experiments confirmed all rules still held as of February 2023.
-
Starting October 3, 2022, more than 100 users reported simultaneous blocking of TLS-based circumvention servers running Trojan, Xray, V2Ray TLS+WebSocket, VLESS, and gRPC. Blocking was port-specific initially (mainly port 443, but also non-443 ports), then escalated to full IP blocking when users switched ports. Domain names were not added to DNS or SNI blocklists. naiveproxy was notably not affected. The blocking was dynamic in at least some cases (browsers could still reach the port, but circumvention tools could not), strongly indicating protocol-level identification rather than blind port blocking.
-
The October 2022 blocking wave is the confirmed operational deployment of the fully-encrypted-traffic detector later formalized in Wu et al. (USENIX Security 2023). The detector was therefore in live production from at least late 2022, more than a year before the academic paper describing it was published. This event establishes that the GFW's passive fully-encrypted classifier operates at scale in adversarial real-world conditions, not just in controlled experiments.
-
V2Ray clients emitted TLS ClientHello messages with a hardcoded, rarely-seen ciphersuite (fingerprint ID 8c48b95f67260663 on tlsfingerprint.io) that allowed a machine-learning classifier to identify V2Ray TLS traffic with 0.9999 accuracy; the same classifier could not accurately identify the traffic after the fingerprint was changed. The blocking rule based on the unique ciphersuite could be expressed in a single iptables line.
-
VMess servers exhibit inconsistent TCP connection-draining behavior depending on error type: a first-seen (Encryption IV, Encryption Key) pair waits for more data before closing, while a replayed pair closes immediately. This timing asymmetry allows a prober to distinguish VMess servers from non-VMess servers with a three-connection probe sequence (M1, M2, M2 replay), as documented by @nametoolong in June 2020.
-
VMess authentication uses a timestamp-based credential with a maximum 120-second (average ~60-second) expiration window, allowing an attacker to replay a captured legitimate request within that window. By making 16 connections with altered Encryption Key bytes that enumerate all 16 possible Margin P padding-length values, a prober can confirm a VMess server by observing a non-repeated set of connection-close byte counts spanning a delta of 15.