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