FOCI 2018: MultiFlow: Cross-Connection Decoy Routing using TLS 1.3 Session Resumption

[David Fifield]

MultiFlow: Cross-Connection Decoy Routing using TLS 1.3 Session Resumption
Victoria Manfredi and Pi Songkuntham
https://censorbib.nymity.ch/#Manfredi2018a
https://www.usenix.org/conference/foci18/presentation/manfredi

MultiFlow is a decoy routing design that is non-blocking and works on
asymmetric routes. One of the challenges of asymmetric decoy routing is
in checking what this paper calls "client liveness": that the TLS
connection under consideration by the decoy router really represents a
live, end-to-end connection between the client and decoy host, and is
not, for example, a replay attack by the censor trying to unmask an
existing decoy routing session. Symmetric decoy routing systems get a
client liveness check for free: because the decoy router sees both
directions, it can see whether the client handshake is accepted by the
decoy host, which a replayed handshake will not be. Section 2 of this
paper examines how (and whether) existing asymmetric systems deal with
client liveness. MultiFlow does it by taking advantage of TLSv1.3
session resumption. As in other asymmetric systems, the client
steganographically exfiltrates crypto keys to the decoy router; once the
decoy router has enough information to resume a session, it initiates
its own, parallel TLS connection to the decoy host as if it were
resuming the client's session. If the resumed session is accepted by the
decoy host, then the connection passes the client liveness check.

As in TapDance (https://censorbib.nymity.ch/#Wustrow2014a) and Rebound
(https://censorbib.nymity.ch/#Ellard2015a), the MultiFlow client, in the
process of doing a TLS handshake with a decoy host, exfiltrates certain
downstream-only information with the decoy router, namely the server's
cipher_suite and key_share, and Transcript-Hashes of the server's
messages. This exfiltration effectively enables the the decoy router to
see the relevant parts of the downstream—which is how MultiFlow works
over asymmetric routes—and enables the decoy router to recover the
master secret and decrypt future upstream messages. The client then
sends a message (an HTTP request, for example) that somehow encodes the
current session ticket. The decoy router can decrypt the message and
recover the session ticket, allowing it to perform session resumption as
if it were the client. At this point, the decoy router initiates a
separate, parallel TLS connection to the decoy host and attempts to
resume the client's session: if it succeeds, the protocol proceeds;
otherwise it halts. This separate TLS connection's only purpose is to
check if the session resumption succeeds; it is otherwise unused (except
as an optimization in a special case).

The client sends upstream data (for example, a request that the decoy
router fetch a censored web page) by encoding it into encrypted
application records, which the decoy router can read because it has the
keys. Downstream data goes over a different channel—remember that the
route may be asymmetric, and the decoy router may not even see the
downstream data sent by the decoy host to the client. The decoy router
sends data back to the client by storing it on some third-party "message
board" service—for example a pastebin-like site, an email server, or a
cloud storage service—using credentials so that only the client can read
the information posted there. A MultiFlow client has to manage two
simultaneous connections: one through the decoy router to the decoy host
(for sending upstream data), and another to the third-party message
board service (to receive downstream data). (As a special-case
optimization, when the decoy host happens to *also* be a suitable
message board service, the client can read and write to it using its
single connection through the decoy router. The decoy router may also
reuse its client-liveness connection to post messages back to the
client. This situation is illustrated as "Tunnel 1" in Figure 4.)