GFW-injected RST packets are distinguishable from legitimate endpoint RSTs by TTL: in the authors' 2006 experiments forged resets carried TTL=47 while genuine server packets carried TTL=39, consistent with the IDS sitting 8 hops closer to the client than the destination server. A 20-line FreeBSD kernel patch implementing TTL-divergence filtering was developed and demonstrated positive results in practice.

Post-trigger blocking persisted for an average of ~20 minutes (observed range: a few minutes to nearly an hour) per source-IP/destination-IP pair, but was scoped to the 128 TCP port numbers sharing the same 7 most-significant bits as the triggering connection's ephemeral port. On pseudo-random ephemeral-port systems such as OpenBSD, the probability of a subsequent connection falling in the blocked port range is only ~1 in 500; on sequential-port systems such as Windows, an average of 64 further connections are blocked.

§6.1 evaluation

In measurements conducted over 10 days in early February 2006, the GFW scanned approximately two-thirds of packets from a 256-address block per hourly probe, with address selection following a structured (non-random) pattern consistent with simple modular assignment to a limited pool of IDS devices. After several days, the inspected fraction rose to nearly all addresses, suggesting a configuration change to expand capacity.

§6.1 evaluation

The GFW's keyword-blocking mechanism relies entirely on endpoints honoring injected TCP RST packets; because the IDS operates out-of-band and cannot remove packets already queued in the router's transmission path, configuring both endpoints to silently discard incoming RSTs (e.g., via `iptables -A INPUT -p tcp --tcp-flags RST RST -j DROP`) allows blocked content to transfer unimpeded. In a controlled experiment, 28 injected RSTs were ignored and the complete blocked web page was successfully retrieved.

§5 defense

The GFW performs no stateful TCP stream reassembly, inspecting one packet at a time: splitting the blocked keyword '?falun' across two TCP segments is sufficient to evade detection entirely. Cross-device state is also absent — triggering a block on one border AS (e.g., AS9929) had no effect on traffic transiting a different Chinese border AS.

§4.1 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 CVE system is structurally incapable of tracking cross-vendor architectural vulnerabilities: in 2019 MITRE correspondence the authors were told CVE identifiers apply only to specific software implementation mistakes and that CVE-2019-14899 'should not have been assigned,' leaving the architectural VPN inference attack surface permanently untracked. Between CVE-2019-14899 (2019) and CVE-2024-49734 (2024), no new CVE was assigned despite continued reporting and confirmed exploitability, creating a five-year gap in the public record during which vendor patch claims went unchallenged.

2026-tolley-architectural §3.1, §4.1, §6.4 traffic-shaperst-injection

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 server-side variant of the blind VPN inference attack—where an in/on-path adversary exploits predictable NAT assignment and tunnel routing semantics to inject spoofed packets indistinguishable from legitimate encrypted traffic—has remained unacknowledged and unmitigated across all tested platforms since its concurrent disclosure in 2019. Unlike the client-side variant, which received partial fixes from Google (CVE-2019-9461, CVE-2024-49734) and Apple (iOS 17.2.1), no vendor has proposed a viable remediation or claimed ownership of the server-side attack surface.

2026-tolley-architectural §2.1, §3.1, §3.4 traffic-shaperst-injectionmiddlebox-interference

An internet-wide scan of 500k IP addresses from an in-country VPS vantage point found TCP establishment-interception injections on 43,479 addresses (8.7% of scanned), with over 70% concentrated in two Akamai ASes (AS16625 and AS20940). The injection pattern — triggered by the first packet sent to these addresses — is consistent with targeted blocking of domain-fronting proxies hosted on Akamai CDN.

2025-alaraj-iran-refraction §4.1.2 packet-injectionrst-injectionip-blocking