<div dir="ltr">Good point about joining the swarm. This is a part of the design that i'm not confident about, it's definitely questionable.<div><br></div><div>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.</div><div><br></div><div>ODDITIES</div><div><br></div><div>1. <b>File content</b>. 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). </div><div><br></div><div>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.</div><div><br></div><div><br></div><div>2. <b>Contact files</b>. 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. </div><div><br></div><div>This aspect that the server keeps refreshing its files is odd.</div><div><br></div><div>These files are part of the server descriptor.</div><div><br></div><div>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.</div><div><br></div><div>Possible ways:</div><div>* 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.</div><div>* 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.</div><div><br></div><div>3.<b>Upload slots per torrent = 1 . </b>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. </div><div><br></div><div>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.</div><div><br></div><div><br></div><div>ABOUT BITTORRENT</div><div><br></div><div>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)</div><div><br></div><div>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.</div><div><br></div><div>Having the infohash means you can fetch the torrent file.</div><div><br></div><div>Spec is here</div><div><a href="https://wiki.theory.org/BitTorrentSpecification" target="_blank">https://wiki.theory.org/BitTorrentSpecification</a><br></div><div><br></div><div>POSSIBLY BETTER DESIGN</div><div><br></div><div>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.</div><div><br></div><div>Tech limitations </div><div><br></div><div>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.</div><div><br></div><div>A solution could be to intentionally join seeder-only swarms that just sit there.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>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.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 2, 2015 at 2:01 PM, David Fifield <span dir="ltr"><<a href="mailto:david@bamsoftware.com" target="_blank">david@bamsoftware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, Feb 28, 2015 at 10:46:03AM -0800, Dan Cristian Octavian wrote:<br>
> My name is Dan, I've been working on a pluggable transport for Tor based on<br>
> bittorrent as cover traffic and wanted to let you know about it.<br>
><br>
> <a href="https://github.com/danoctavian/bit-smuggler" target="_blank">https://github.com/danoctavian/bit-smuggler</a><br>
><br>
> In a nutshell, I'm tunnelling a data stream through a bittorrent peer<br>
> connection that is created by real bittorrent clients (uTorrent for this<br>
> implementation) - to avoid "parroting" traffic pitfalls and active probing.<br>
> This made the implementation quite tricky to get right, so my reasoning is that<br>
> it's a worthy trade-off.<br>
<br>
</span>People reading this should look at the documentation, there's thoughtful<br>
information there.<br>
<br>
<a href="https://github.com/danoctavian/bit-smuggler/blob/master/README.md" target="_blank">https://github.com/danoctavian/bit-smuggler/blob/master/README.md</a><br>
<a href="https://github.com/danoctavian/bit-smuggler/blob/master/DESIGN.md" target="_blank">https://github.com/danoctavian/bit-smuggler/blob/master/DESIGN.md</a><br>
<a href="https://github.com/danoctavian/bit-smuggler/blob/master/docs/system-components.png" target="_blank">https://github.com/danoctavian/bit-smuggler/blob/master/docs/system-components.png</a><br>
<br>
I don't know anything about BitTorrent. What parts of the protocol are<br>
easily visible to the censor, without expensive reconstruction? I guess<br>
it includes at least: file names, file sizes, peer IP addresses.<br>
<br>
About active probing: it's true that if the censor probes you, you look<br>
like a BitTorrent client. Is there anything weird about how you use the<br>
protocol that could make you stand out anyway? At<br>
<a href="https://github.com/danoctavian/bit-smuggler/blob/master/README.md#security" target="_blank">https://github.com/danoctavian/bit-smuggler/blob/master/README.md#security</a>,<br>
you say that a network monitor would have to reconstruct a stream in<br>
order to detect anomalies. Could a censor acting as an ordinary peer<br>
detect them more easily, just by participating in the file transfer?<br>
(I'm thinking of how the movie studios would run their own BitTorrent<br>
clients in order to find other downloaders.)<br>
<span class="HOEnZb"><font color="#888888"><br>
David Fifield<br>
</font></span></blockquote></div><br></div>