TapDance introduces chosen-ciphertext steganography, which allows the client to embed an arbitrary-length hidden message inside a valid TLS ciphertext without invalidating the TLS MAC or session. By exploiting ciphertext malleability in both stream-cipher (counter) mode and CBC mode, the client can choose specific byte values to appear in the ciphertext while constraining plaintext to a safe ASCII range (0x40–0x7F), encoding 6 bits of tag data per ciphertext byte. This provides unbounded covert-channel bandwidth, compared to the fixed 224-bit TLS nonce used by Telex and Decoy Routing or the 24-bit TCP ISN used by Cirripede.

Asymmetric IP routing is a fundamental constraint on prior E2M designs: tier-2 ISPs typically see around 25% of packets on asymmetric paths, while tier-1 ISPs can have up to 90% of packets on asymmetric flows. Because Telex requires observing both directions of a connection to derive the client-server TLS master secret, this asymmetry severely constrains where it can be deployed. TapDance resolves this by using chosen-ciphertext steganography to leak the master secret from client to station in a single upstream packet, making it functional under fully asymmetric routing.

§1, §6 evaluation

All three prior end-to-middle (E2M) schemes — Telex, Cirripede, and Decoy Routing — require an inline flow-blocking component at the participating ISP, which adds latency, introduces a single point of failure, and may violate carrier SLAs. In private discussions with ISPs, the authors found that despite willingness to assist Internet freedom technically and financially, none were willing to deploy existing E2M technologies due to these operational impacts. TapDance removes the inline blocking requirement entirely, requiring only a passive tap and packet-injection capability.

§1, §6 deployment

Scanning a 1% sample of the IPv4 address space and the Alexa top-1-million domains, the authors found that over half of all TLS hosts will leave an incomplete HTTP request connection open for at least 60 seconds before sending data or closing the connection; many had timeouts exceeding 5 minutes. The 16-core TapDance station prototype processes over 12,000 tag verifications per second per core, with approximately 90% of CPU time consumed by a single ECC point multiplication on Curve25519. The station adds a median latency of 270 milliseconds to page downloads versus direct connections, and a single station instance can be overwhelmed by approximately 1.2 Gbps of TLS application-layer traffic.

§7.3, §8, Figure 5 evaluation

Because TapDance does not block client-to-server packets, a censor can inject a TCP packet with a stale acknowledgment number directly to the true decoy server; the server will reply with its actual TCP sequence state, which will differ from the sequence numbers the TapDance station has been using — confirming the flow is proxied. This active packet-injection attack is qualitatively easier to execute against TapDance than against Telex or Cirripede, which used inline blocking to prevent such probes from reaching the server. Table 1 in the paper confirms that TapDance, unlike Telex, lacks replay/preplay attack resistance and has no traffic-analysis defense.

§5.2, Table 1 detection

State-of-the-art ML-based obfs4 detection (Wang et al. decision tree) achieves 97% precision at equal base rates (λ=1) but precision collapses to 3% at a still-conservative λ=1,000; at λ=10⁶ precision approaches zero for all classifiers tested. This base-rate failure was previously uncharacterized because prior evaluations only considered balanced or near-balanced datasets.

2024-wails-precisely §IV-D (Scalability), Figure 3, Table I ml-classifierrandom-payload-detectdpi

The GFW detects Shadowsocks by flagging apparently high-entropy connections that are not TLS or HTTP, but this detection is brittle: connections are explicitly allowed if the first 6 bytes of the first packet of a flow are all printable ASCII characters (range 0x20–0x7E). Adding a 6-byte alphanumeric preamble to the Shadowsocks message definition is sufficient to bypass this heuristic and requires only a short patch to the protocol specification file.

2023-wails-proteus §3.2 random-payload-detectfully-encrypted-detectdpi

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.

2023-wu-fully-encrypted-detect §4, Algorithm 1 fully-encrypted-detectdpirandom-payload-detect

Current randomized-payload circumvention tools (obfs4/ScrambleSuit, SkypeMorph, VoIP-tunneling) rely on censors 'defaulting open' — treating unidentified traffic as innocuous. If censors instead block all traffic not explicitly recognizable as meaningful plaintext, these tools fail entirely. The paper notes anecdotal evidence this is already occurring, including blocking of some TLS 1.3 connections.

2021-kaptchuk-meteor §1 Introduction random-payload-detectfully-encrypted-detectdpi

The GFW's passive classifier uses two features of the first data packet to flag probable Shadowsocks traffic: (1) high Shannon entropy (per-byte entropy > ~7 bits strongly correlates with replay probability, which is nearly 4x higher at entropy 7.2 than at 3.0) and (2) packet length in the range 160–700 bytes with specific remainders mod 16. A single data packet after the TCP handshake is sufficient to trigger the downstream active-probing pipeline.

2020-alice-shadowsocks-detection §4.2 dpirandom-payload-detecttraffic-shape

Measured packet loss rates under GFW censorship (Feb–Apr 2017, client at Tsinghua University/CERNET): Tor with meek obfuscation suffers 4.4% average PLR; Shadowsocks (AES-256-CFB) suffers 0.77% PLR; native VPN (PPTP/L2TP) and OpenVPN both achieve ~0.21% PLR. For comparison, the same tools accessed from a US vantage point show PLR below 0.1%, confirming the excess loss is GFW-induced. The GFW's DPI and active probing techniques specifically target Tor and Shadowsocks protocol signatures.

2017-lu-accessing §4.3 dpiactive-probingrandom-payload-detect