The root vulnerability in ShadowTLS is that the relay cannot authenticate post-handshake data from the real mask site, causing it to silently absorb censor probes. The fix — deployed in ShadowTLS v0.2.3 — has the client re-derive the Application Data encryption key from the server random and the client-relay shared secret; unrecognized records (lacking the shared secret) are transparently forwarded to the mask site, so all censor-visible responses come from the real mask server.

Combining all three active probing attacks in an Internet-wide scan of 30 million HTTPS servers identified approximately 15,000 hosts (0.05%) behaving like ShadowTLS relays; of these only 6,000 presented TLS certificates for Alexa Top 1000 domains. The scan successfully discovered all four researcher-operated ShadowTLS relays planted as ground truth.

§3.2, Table 2 evaluation

ShadowTLS relays are detectable via three active probing techniques exploiting behavioral discrepancies from the mask sites they mimic: (1) responding to plaintext HTTP on port 443 with FIN-ACK rather than an error (only 17% of TLS servers share this behavior), (2) silently ignoring non-TLS record data post-handshake rather than sending a fatal alert (only 0.14% of 30M hosts behaved this way), and (3) silently ignoring corrupted TLS Application Data records rather than sending a bad_record_mac alert (only 0.12% of hosts silent).

§3.2 detection

ShadowTLS is structurally limited to TLS 1.2 because in TLS 1.3 the Finished message is sent as encrypted Application Data (record type 0x17), preventing the relay from detecting handshake completion without decrypting the session. This forces ShadowTLS to advertise TLS 1.2, which is an increasingly anomalous fingerprint as TLS 1.3 adoption grows.

§2.2 detection

ShadowTLS's TLS ClientHello fingerprint (JA3 hash ebaa863800590426) was not observed in the TLSFingerprint.io dataset collected from a university network tap, making the client fingerprint unique to the tool and trivially blockable by censors maintaining a TLS fingerprint blocklist.

§3.2 detection

Re-testing in 2025 on a Pixel 10 Pro XL running Android 16 with October 2025 security updates confirmed that blind in/on-path VPN inference attacks remain fully viable despite CVE-2019-9461, CVE-2019-14899, and CVE-2024-49734 having been formally closed. All three core attack primitives—VPN-assigned internal IP discovery, active connection inference, and TCP reset injection via sequence/acknowledgment window scanning—succeeded across OpenVPN, WireGuard, and NordLynx.

2026-tolley-architectural §5.1–5.3 traffic-shaperst-injectionactive-probing

Six widely deployed VPN and circumvention tools—OpenVPN, WireGuard/NordLynx, NordWhisper, Orbot (Tor on Android), Lantern, and Psiphon—all failed to block internal IP inference, connection-state detection, and TCP reset injection under identical adversarial conditions on fully patched Android 16. Application-layer obfuscation in Lantern and Psiphon did not prevent TCP-layer disruption; Orbot's VPN-style encapsulation of Tor traffic was bypassed via the same tunnel-level side channels.

2026-tolley-architectural §5.2, §5.4–5.5 traffic-shaperst-injectionactive-probing

The paper proposes an Internet Freedom vulnerability registry with five design principles: persistent cross-vendor tracking under shared identifiers (e.g., IF-ARCH-2025-001) as long as a risk remains reproducible; human-centered impact ratings anchored to harm potential for journalists and dissidents rather than CVSS-style exploitability scores; timestamped re-verification hooks with linked PCAPs and minimal reproduction scripts; a structured media interface to counter vendor narrative capture; and open public APIs for integration into risk dashboards so that users of tools like Orbot or Lantern can directly query their configuration's exposure to known metadata-based attacks.

2026-tolley-architectural §6.1–6.5 traffic-shaperst-injectionactive-probing

The September 2025 leak of ~600 GB from Geedge Networks and the MESA Lab (Institute of Information Engineering, Chinese Academy of Sciences) is the largest known document disclosure from the GFW vendor ecosystem. It establishes a direct lineage: MESA Lab (founded 2012 by Fang Binxing's team, annual contracted revenue >35M RMB by 2016) spun out Geedge Networks in 2018, with MESA alumni filling key engineering roles (e.g. Zheng Chao as CTO). The leak includes ~64 GB of MESA git repositories, ~35 GB of MESA internal documents, ~15 GB of Geedge internal documents, and a ~3 GB Jira export — providing direct access to source code, work logs, and internal communications behind GFW R&D.

2025-geedge-mesa-leak §4 dpiactive-probingml-classifiersni-blockingfully-encrypted-detect

Internal Geedge documents confirm active contracts to deploy GFW-derived censorship and surveillance infrastructure in Myanmar, Pakistan, Ethiopia, Kazakhstan, and at least one additional unidentified country under the Belt and Road framework, in addition to domestic deployments in Xinjiang, Jiangsu, and Fujian. The exported product (the Tiangou Secure Gateway / TSG line) is not a stripped-down export variant — leaked TSG documentation shows DPI, active-probing, ML classifiers, and granular per-region traffic control rules that mirror the domestic GFW capability set.

2025-geedge-mesa-leak §5, §6 dpiactive-probingml-classifiersni-blockingdns-poisoningfully-encrypted-detecttraffic-shape

InterSecLab frames the Geedge/TSG export program as the commoditization of national firewall capability: rather than each censor state independently developing detection infrastructure, they contract Geedge for a turnkey system incorporating the cumulative R&D of MESA Lab (>10 years, National Science and Technology Progress Award winners). This structural shift means the marginal cost for an autocratic government to acquire GFW-grade censorship is now a procurement decision, not a multi-year engineering program. The report identifies that Geedge's relationship with the MESA Lab gives customer states indirect access to ongoing academic R&D improvements, not just a static product.

2025-interseclab-internet-coup §2, §6–§7 (InterSecLab report) dpiactive-probingml-classifier