Btsync Stars On Httpshaming

[freigeist]

On the web security page http://httpshaming.tumblr.com/post/95206154681/bittorrent-sync-requests-its-tracker-relay-and

Btsync is blamed to communicate insecure. I can't judge this. Are the accusations valid?

[hungarianhc]

Oh that is very interesting...

[richdotward]

Any chance of an official answer from the developers? Should we be worried ?

Rich

Sent from my Nexus 4 using Tapatalk

[Harold Feit]

Coming from the main client side of things (not sync), I'd say that this is just a scaremongering tactic.

Knowing the tracker address is all fine, but if it doesn't give out any information about who else is on it, or what is being shared through it.

They show no peer-identifying or secret-identifying communication in their posted logs, therefore they show no actual insecurity in the protocol or client.

[N4TE_B]

Thanks for bringing this up.  We'll take a look at it and determine the validity of the claim.

 

We appreciate you guys keeping watch!

[capi]

I just posted the following discussion to this blog entry, and I think it is also a valid repsonse here, but I am really looking forward to some official answer:

 

The question is, how far this really leads to exposure of data. The claim is, that tracker and relay only ever see encrypted content (hash of secrets for the tracker, encrypted data for the relay). So if this claim is true (and this can neither be verified nor rejected based on the information here), the attack scenario is, that someone could do a DoS on sync, i.e. prevent peer discovery via tracker to fail by forcing an invalid tracker, but could not extract any shared data.

[phkn1]

Hi all,

 

I submitted the original post and while I agree that fetching the list of trackers in the clear isn't itself insecure, it does raise questions about the end-to-end exchange.  The subsequent connections appear to be encrypted, though I haven't analyzed them in detail, they do "nonce" here and there and generally look sufficiently unintelligible as to provide confidence.  That being said, I guess the primary concern is whether an attacker could inject or induce a connection to an untrusted tracker and thereby cause a client to disclose its secret key, protected data, or surreptitiously join a swarm.

 

E.G.:  A MITM/ session-replay attack which captures the initial exchange, forwards it to a malicious peer, and proxies the rest of the connection.  Just because the connection is encrypted does not ensure that its initial identity is known.

Edited August 20, 2014 by phkn1

[kos13]

Developer is here.

 

This was done intentionally, so anyone could verify the data that is sent to tracker server. The data contains absolutely no private information or the way to get access to private data and you could easily verify that. All data that has private data is encrypted on client side and you could verify that by looking to traffic that goes thru relay server. 

 the attack scenario is, that someone could do a DoS on sync, i.e. prevent peer discovery via tracker to fail by forcing an invalid tracker, but could not extract any shared data.

 

Attacker could only make establishing new connections harder or impossible. Beauty of Sync is that it is fully distributed and true p2p solution, so if we will see these attacks you can do few simple things (DHT, predefined peers) and your instance of Sync will continue working. 

 

 

E.G.:  A MITM/ session-replay attack which captures the initial exchange, forwards it to a malicious peer, and proxies the rest of the connection.  Just because the connection is encrypted does not ensure that its initial identity is known.

 

We are aware of this type of attack and it won't work against of Sync. I understand that these are just my words and it worth nothing when we talk about security. We will have more official info about this soon. This info will work better than my words

 

kos

[capi]

We will have more official info about this soon. This info will work better than my words

 

I hope this means what it implies it means Looking forward to this "official info" very much Thanks for your hard work!

 

And basically you confirmed what I tried to write in my answer. No data leakage but some potential troubles with the tracker / relay, but as you said, there are other means of peer discovery.