[tor-dev] bittorrent based pluggable transport

[l.m]

> It's a mistake to say that if something doesn't
> work in China (or any other single concrete 
> threat environment), then it's useless.

Out of respect for the work you've done I'm not going to assume you're
taking typed-word out of context incorrectly.

I'm concerned that this PT exchanges one threat for another and is
thought to be a good for integration with Tor. It's one thing to use
Google/Azure/etc where there are legitimate uses. It's another to
trade the threat of secure-encrypted traffic (with crypto-secure PRNG
in most PT cases) for another option that utilizes insecure
obfuscation of file transfer together with a server that utilizes
(presumably) secure communication. In one you increase vulnerability
surface of the censored user, in the other the only threat is this
unknown communication which can be easily blocked. I digress.

Allow me to attack the problem head on then. What do I know about
bitorrent. Not much. I know, for any user of bitorrent, the infohash
is easily derivable and so is the peer list. So, if you don't
participate in the swarm intersection of peer lists means it's less
difficult to find the needle-in-the-haystack that is the PT-server.
Just look at the unique peers across multiple users of the PT who each
create unique torrent swarm fingerprints corresponding to the infohash
of the files shared. You, the PT-server, must participate in the
swarm.

Suppose then that you, the PT-server, do participate in the swarm.
Long transfers with peers who provide hash-failing pieces breaks BT
spec. The adversary just needs to force peer list rotation. How can
this be done? Well, the adversary knows the infohash and the peer list
to expect. So, flip-bit, as you put it. Only do it for all peers who
cross the country-firewall. If the client is indeed running a
bitorrent client sit back and watch the churn. Only something stands
out. There's a peer, you, the PT-server, who is ignoring the ban
fingerprint. This can be done in either direction of piece share.
Because you the the PT-user differ from the spec you stand out.

Another case. The adversary can monitor the bitfield of the peer
connected to the PT-server. When the torrent is complete the client
will disconnect from all peers and take the seed role. Only there's a
problem. They're still transferring data with the PT-server as if they
were a leech. It's not enough to change torrent swarms because it
would be immediately apparent that they re-establish communication
with the PT-server, crossing swarms.

A final thought. It's one thing for an adversary to not be able to
attack a communication besides blocking it entirely. This would be the
case with crypto-secure communications. Bitorrent doesn't fall into
this category. Especially when facing the state-level adversary. So
your PT communication would need to be crypto secure (not saying it's
not). The caveat is that if one were to try and pack encrypted data
within BT-spec obfuscation and that BT-spec obfuscation better not
ever fail. If it did the user of the PT can be proven to be hiding
data via steganography in hash failing pieces (as you've mentioned).
This can provide justification for an accusation of state-offense.
This would be different from packing data where no hash fail is
apparent such as regular steganography, minus bittorrent. Video
streaming or audio streaming combined with data hiding, and without
any checksum, is a different beast than video transfer over BT.

tl;dr -- It's a novel idea to prevent detection of the PT-server by
tunneling in some other traffic.
--leeroy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150304/2b244ed6/attachment.html>