Re: [tor-dev] bittorrent based pluggable transport

["l.m" <ter.one.leeboi@xxxxxxxx>]

> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev