[anti-censorship-team] TurboTunnel Packet Scheduler Tips and Traffic Analysis Benefits

[Mike Perry]

Hi all,

I recently posted a draft proposal for traffic splitting for Tor:
https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/329-traffic-splitting.txt

It has similar properties as TurboTunnel, but I put quite a bit of work
and consulted with several TCP and multipath TCP researchers to develop
the packet scheduling algorithms defined in Section 3:
https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/329-traffic-splitting.txt#L389

You may be interested in adopting those algorithms, if possible. There
are variants that optimize for latency, throughput, or both in combination.

The proposal also supports resumption of closed circuits.

I am writing this mail because while these things are nice, resumption
in particular does not defend against all classes of issues I am worried
about with respect to confirmation attacks from closing or blocking
connections, particularly onion service connections:
https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/329-traffic-splitting.txt#L657

Briefly, if an adversary suspects an onion service is in use at a
particular guard, it can make a circuit to that onion service, hold it
open, and then close TCP connections of that guard to see if the circuit
closes.

This can even be done on the side with TCP RST injection, and possibly
even blindly with brute force RST spoofing and spamming, if a good
enough guess can be made about the IP address range of the service.

Worse, in this case, the resumption I specified for Conflux does not
help here, because this adversary will see the service's resumption
attempt, and use that for confirmation instead of circuit close.

TurboTunnel's resumption and automatic bridge discovery and replacement
should greatly mitigate this attack, because it happens at a layer that
is not necessarily controlled by the adversary, and thus resumption is
mostly invisible to them (save for delay, which Cecylia is working on
minimizing).

Additionally, since traffic splitting has been shown to help against
website fingerprinting, it stands to reason that doing traffic splitting
at multiple layers and multiple endpoints may actually be better than
doing it at just one layer, and costs us little-to-nothing in terms of
overhead:
https://www.comsys.rwth-aachen.de/fileadmin/papers/2020/2020-delacadena-trafficsliver.pdf


So please, keep on improving TurboTunnel! And let's compare notes about
what we learn! Looking forward to obfs4 TurboTunnel, too!


-- 
Mike Perry