China's GFW blocks all ESNI traffic via RST packet injection following a TLS ClientHello with an encrypted SNI field, confirmed since July 2020. Russia blocks ESNI in a decentralized, ISP-level fashion across at least three identified ASes (AS28890, AS52207, AS41754), each injecting RST packets independently.

DNS manipulation is widespread across China (305 domains via local resolvers, 300 via public resolvers) and Russia (251 local, 205 public), but simply switching to a public DNS resolver already evades local-resolver-only filtering for many domains, reducing apparent censorship at the public-resolver layer. On-path filtering systems that poison queries to public resolvers represent a harder threat class requiring encrypted DNS.

§4.1, Table 2 evaluation

Using DoH plus ESNI, DNEye successfully unblocked 130/230 (56%) of DNS-filtered domains in China and 53/56 (95%) in Russia, but 0/49 (0%) in Iran. The primary failure mode in China (84 domains) and Iran (47 domains) was SNI-based filtering at the TLS layer for domains that do not support ESNI, which remains visible in the ClientHello.

§4.3, Table 3 evaluation

DNEye detected DoTH (DoT and DoH) blocking across the largest number of ASes in China, with interference against Cloudflare, Quad9, AdGuard, and CleanBrowsing resolvers emerging in early March 2021. Blocking patterns varied per-AS rather than following a centralized GFW DNS-level policy, indicating individual ISP implementation. Saudi Arabia, by contrast, showed coordinated SNI-based blocking of the same DoH resolvers across different ASes, indicating centralized policy.

§4.2, Table 5 detection

Only 1.5–2.25% of domains from TLD zone files have a valid ESNI key, with 15.4K of the top 100K and 143.3K of the top 1M popular domains supporting ESNI. All ESNI-supported domains are hosted by Cloudflare, making ESNI-enabled connections trivially distinguishable from the vast majority of TLS traffic and a low-collateral-damage blocking target for censors.

§4.2 evaluation

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