[tor-dev] bittorrent based pluggable transport

Thu Mar 5 10:48:29 UTC 2015

Hey Leeroy,

On your last point: yeah a traffic capture follows by TCP packet
reconstruction and thus reconstruction of the bittorrent messages and a
check against the original checksums of the pieces (as specified in the
torrent file) will show that a connection was not genuine (very likely it
was bitsmuggler) since failed checksums are probably a rare occurence in
nature.

"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."

Not 100% sure i understand what you mean here. Are you suggesting an attack
that involves tampering with/sending of Peer Exchange messages that say a
certain peer should be banned and then the bit-smuggler owned peers just
ignore it?

I think you are right if you are saying to that messing up the swarm with a
strategy like that or smth else, thus disrupting the communication between
PT server and client would with the current implementation trigger the
client to cross the swarm and seek to connect to the server through another
swarm, and this behavior may be a give-away with real-time results.

I think you make valid points. In general I found bittorrent hard to make
it do what you want and i'm not confident about the current swarm handling
design, that's why i am asking for opinions on whether it can be improved,
or it's not fit to be used as a PT.

On the issue of broken checksums there is no solution for real-time
communication if you want to prevent an adversary to be unable to infer
that a bit-smuggler connection is hiding behind a bittorrent one (in same
way it's unable to detect some steganographied message inside a picture).
An option may be to use the encrypted bittorrent (yeap it has one). I'm
guessing that encrypted bittorrent connections are rarely used though. An
adversary may simply choose to ban this type of connections without causing
much disruption.

On Wed, Mar 4, 2015 at 3:37 PM, l.m <ter.one.leeboi at hush.com> wrote:

> > 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
>
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150305/e5d6cb8f/attachment.html>