[tor-dev] bittorrent based pluggable transport

Tue Mar 3 02:53:27 UTC 2015

Good point about joining the swarm. This is a part of the design that i'm
not confident about, it's definitely questionable.

Suppose a non-bitsmuggler peer joins the swarm. If he starts torrenting the
file, he will get a correct copy (no checksum fails on the pieces) of it
because all bitsmuggler parties hold a full correct copy of it to begin
with.

ODDITIES

1. *File content*. However, as described in the docs, at the moment those
files are just random data, generated with a pseudo-random generator using
an integer seed. So an entropy analysis of the the file may be a give-away
(the fact that it doesn't look like anything really) and also the fact that
right now the percentage of the file that is available is fixed (1/2).

a solution here is to use real existing files, but this involves pre
downloading them (fetch pirates of the Caribbean 3 first and then torrent
it again with your bit-smuggler server).  how much of the file is available
can be randomized.

2. *Contact files*. Another aspect is that the server now works by
advertising a set of so called contact files. those contact files are
bittorrent files that a client needs to start downloading to tunnel a
bit-smuggler connection through them. They are partially completed files
(1/2 of the pieces are there). Once they are depleted (all downloadable
pieces are downloaded) the file is removed and a new partial copy is placed
in, to allow for new peer connections on that contact file to have plenty
of data flowing back and forth.

This aspect that the server keeps refreshing its files is odd.

These files are part of the server descriptor.

Another way of doing it could be deciding the contact files dynamically.
You could maybe have a small exchange at the very beginning between the
server and the client through some other channel and steg some data in
there.

Possible ways:
* the client can make a DHT request for the server, and the server would
reply with a set of nodes, but the data in the reply contains data about
what contact file the client should use, so not a correct DHT query
response.
* ue the bifield message of bittorrent to do a request-response sequence
between the bitsmuggler server and client about what contact file to use
and then switch to it.

3.*Upload slots per torrent = 1 . *the client and server instruct their
bittorrent clients to upload to a single peer. basically i'm restricting
swarms to a size of 2 to load balance things. if i disable this it would
just mean the file gets depleated faster.

So actually, given this setting, an outsider joining a swarm where a
bit-smuggler server and client live would not actually be able to download.

ABOUT BITTORRENT

On bittorrent: it's wire protocol is not very complicated. traditionally it
runs over a TCP connection, starts with a handshake (containing infohash (
the ID ) of the file transferred and the ) and continues with length
prefixed messages which are mostly piece requests and piece data messages
(the ones where i embedd the payload) + some control messages to control
the data flow (choke, unchoke, interested)

The handshake you can probably yank it out with a regex easily at IP level
without any packet reconstruction. the rest i guess you need to parse the
stream at application level to make sense of it.

Having the infohash means you can fetch the torrent file.

Spec is here
https://wiki.theory.org/BitTorrentSpecification

POSSIBLY BETTER DESIGN

the bitsmuggler server joins aribtrary existing swarms on the internets and
informs the client somehow which swarms to look for it. once they find each
other, they start exchanging data.

Tech limitations

A crappy thing about utorrent's interface is that it doesn't allow you to
tell it to look for a certain peer (so bitsmuggler client tells its
bittorrent process to just look for the bitsmuggler's bittorrent process in
a big swarm). So who you connect to in a swarm is arbitrary.

A solution could be to intentionally join seeder-only swarms that just sit
there.

If you are to not break the file integrity for the other peers you better
have a copy of that file of whose swarm you are joining ahead of time. but
this is necessary with the current design as well.

Any suggestions/comments are very welcome. IT seems to me that bittorrent
is very hard to tame compared to let's say HTTP as a cover between a server
and a client, so this might be an impairing limitation for the project.

On Mon, Mar 2, 2015 at 2:01 PM, David Fifield <david at bamsoftware.com> wrote:

> On Sat, Feb 28, 2015 at 10:46:03AM -0800, Dan Cristian Octavian wrote:
> > My name is Dan, I've been working on a pluggable transport for Tor based
> on
> > bittorrent as cover traffic and wanted to let you know about it.
> >
> > https://github.com/danoctavian/bit-smuggler
> >
> > In a nutshell, I'm tunnelling a data stream through a bittorrent peer
> > connection that is created by real bittorrent clients (uTorrent for this
> > implementation) - to avoid "parroting" traffic pitfalls and active
> probing.
> > This made the implementation quite tricky to get right, so my reasoning
> is that
> > it's a worthy trade-off.
>
> People reading this should look at the documentation, there's thoughtful
> information there.
>
> https://github.com/danoctavian/bit-smuggler/blob/master/README.md
> https://github.com/danoctavian/bit-smuggler/blob/master/DESIGN.md
>
> https://github.com/danoctavian/bit-smuggler/blob/master/docs/system-components.png
>
> I don't know anything about BitTorrent. What parts of the protocol are
> easily visible to the censor, without expensive reconstruction? I guess
> it includes at least: file names, file sizes, peer IP addresses.
>
> About active probing: it's true that if the censor probes you, you look
> like a BitTorrent client. Is there anything weird about how you use the
> protocol that could make you stand out anyway? At
> https://github.com/danoctavian/bit-smuggler/blob/master/README.md#security
> ,
> you say that a network monitor would have to reconstruct a stream in
> order to detect anomalies. Could a censor acting as an ordinary peer
> detect them more easily, just by participating in the file transfer?
> (I'm thinking of how the movie studios would run their own BitTorrent
> clients in order to find other downloaders.)
>
> David Fifield
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150302/4e4a86a6/attachment-0001.html>