MultiFlow mitigates TLS termination attacks—where an adversary drops a connection after one data exchange—by having the client exfiltrate TLS session resumption information (219 bytes: 208-byte psk identity plus ticket metadata) to the decoy router. The decoy router can then resume a session with a different decoy host, establishing a new covert channel even if the original connection is severed, and amortizing per-session setup cost across multiple connections.

MultiFlow's tunnel operates as a virtual message board: the client and decoy router never exchange covert data within the same TCP connection. The decoy router uploads responses to a URI or email address specified by the client; the client downloads independently on a separate connection. This design eliminates the forged-packet and rewritten-traffic vectors that make TapDance and Rebound vulnerable to traffic analysis and decoy-host probing.

§3.2 defense

If an adversary replays captured client handshake traffic to a decoy host under adversary control, and the decoy router attempts to resume the client's session on that host, the adversary can infer that a decoy router is present on the path to the original decoy host. The paper identifies this as a residual probing vulnerability when the client does not encrypt the destination server to which resumption should be directed.

§3.1 detection

MultiFlow's stencil-coding capacity is constrained by TLS record sizes: hiding 1 byte per 16-byte block requires a 1568-byte TLS record to exfiltrate 98 bytes of key material. The paper notes that many websites' initial GET requests produce TLS 1.3 application records under 100 bytes, meaning MultiFlow would need to span multiple records or adopt the more efficient chosen-ciphertext steganography used by TapDance. No implementation exists at time of publication; session resumption from a different source IP was verified feasible using OpenSSL 1.1.1-pre2 and Scapy.

§3.1, §3.4 evaluation

MultiFlow enables a tap-based decoy router to authenticate clients without inline traffic blocking by having the decoy router resume the client's TLS 1.3 session with the decoy host. The client embeds 112-byte sentinel values in the ClientRandom and key-share fields; the decoy router uses the exfiltrated 219-byte NewSessionTicket to perform the resumption. If the decoy host accepts the resumed session rather than falling back to a full handshake, the client is confirmed live.

§3.1 defense

The RKS Global report documents a two-tier Russian censorship architecture: TSPU network-layer blocking (documented by Xue et al. 2024) at the ISP level, now supplemented by mandated app-layer VPN detection in the 30 most popular Russian Android apps. This layered approach means a circumvention tool that successfully bypasses TSPU at the network layer can still be detected and reported by the app layer, closing the gap that network-only circumvention leaves open.

2026-rks-russian-apps-vpn-detection §2, §7 tls-fingerprintml-classifiermiddlebox-interference

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

Russian TSPU devices directly block ECH by dropping ClientHello messages that contain both an ECH extension and the outer SNI hostname "cloudflare-ech.com" — the static outer SNI Cloudflare advertises in all its ECH configurations. Blocking affects both TLS and QUIC. ECH connections to servers with Cloudflare ECH support but outside Cloudflare's official IP ranges are NOT blocked. TCP segmentation alone or TLS record fragmentation alone did NOT bypass TSPU ECH blocking, but combining both techniques did circumvent it. TSPU has also added TCP reassembly capabilities that defeat previously effective fragmentation-only bypasses.

2025-niere-encrypted §5, Figure 5 dpirst-injectionmiddlebox-interference

The GFI's HTTP and HTTPS filters are now stateful (requiring initial SYN packet with matching sequence numbers) and have been activated on all TCP ports—not only standard ports 80 and 443 as reported by prior studies. This is a significant departure from previous work that found stateless HTTP/HTTPS blocking limited to standard ports. The HTTP filter injects a 403 Forbidden blockpage (not RST packets as used by the GFW), while HTTPS injects a single RST+ACK packet. The GFI also exhibits TCP non-compliance (not requiring a full three-way handshake to trigger filtering), enabling outside-in measurement without in-country servers.

2025-tai-irblock §2.1, §3.2 dpirst-injectionpacket-injectionmiddlebox-interference

The Henan Firewall is stateless in two exploitable ways: (1) it requires the TCP header to be exactly 20 bytes—enabling any TCP option (e.g., TCP Timestamps, which Windows disables by default) to bypass it entirely; (2) it does not perform TCP reassembly, so splitting a TLS ClientHello across two TCP segments such that the SNI extension straddles the boundary bypasses the censor. Both bypasses require only client-side changes and have already been implemented in Xray, GoodbyeDPI, and Shadowrocket. TLS record fragmentation (splitting the ClientHello across multiple TLS records within one TCP segment) also defeats both the Henan Firewall and the GFW, since neither performs TLS reassembly.

2025-wu-regional-censorship §4.3 / §6 sni-blockingdpimiddlebox-interference

Longitudinal GFWeb data spanning 20 months shows the GFW actively patched previously-published evasion findings during the measurement period: overblocking bugs reported in academic papers were fixed, and fragmented-packet reassembly failures that researchers used to bypass blocking were corrected. This demonstrates that the GFW operator monitors published research and iterates on the system in response to disclosed vulnerabilities.

2024-hoang-gfweb Abstract, §5.4, §6 dpimiddlebox-interference