2018-manfredi-multiflow
findings extracted from this paper
-
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.
-
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.
-
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.
-
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.
-
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.