Having said that, we do need these kinds of solutions without the back doors. Why aren't any software developers from countries where mandatory backdoors aren't a thing building stuff like BTSync? And does anyone know which countries those are? For example, i live in Belgium. Were I to build such a thing, would someone show up on my doorstep and force me to backdoor it?
(*) nothing that is reasonable, only paranoia and extreme lengths will suffice.
Yeah, but you don't have to make it _easy_ for them, like using closed-source software that's capitalizing on the name recognition of "BitTorrent" to pretend to be open.
(I expect that even if you lived in McLean, Virginia and never locked your doors, if you were writing open-source software, nobody would make you put a backdoor in. The intelligence agencies have shown a great bias towards doing things that people won't notice.)
Also, even assuming you can't keep the NSA and FBI out if they really care (which I somewhat agree with), it's definitely worth it to keep everyone else out. Like BitTorrent the company, or anyone MITMing any of those HTTP URLs.
You do have that. Further, you've had it since 2006.
Point duplicity[1] to rsync.net[2].
Cheers!
> Change of sharing paradigm that introduced this vulnerability happened after the first releases. This may be the result of NSL (National Security Letters, from US Government to businesses to pressure them in giving out the keys or introducing vulnerabilities to compromise previously secure systems) that could have been received by BitTorrent Inc and/or developers.
IF that's true, then it's extremely alarming. I wouldn't use their software to share sensitive files.
At least, that's how any competent developer would code it.
> [MEDIUM] Attack vector potentiel : mise à jour automatique (silent update) du client en HTTP sur http://update.utorrent.com
If they check the digital signature on an update package, this is not an issue. If they don't, it is.
There are ways to mitigate this, but not well given the design constraints of closed-source software.
If you meant that a man in the middle can do that, then if things are implemented correctly on the app's end and if an attacker doesn't have vendor's private key, then - no, of course, they cannot inject anything that way.
> [LOW] confirmed: When registering, http traffic for creating new user on loopback http://127.0.0.1:8888
And I wonder the same. Didn't really get that one, but yeah you may be right that they mean it should be https. I guess the risk is when an application can monitor loopback traffic, but you can only do that with special permissions or if you're root. The former case is exceptional, in the latter case you're pwned anyway and your keystrokes aren't safe either. So yeah, I don't know. Https might do a little bit extra... but I don't know.
If I understood the article correctly, an MITM attacker (or federal agency) could in theory know that you have a copy of a file only after they have a copy of the same file themselves, by comparing hashes.
Bottom line: do not use for sensitive data.
I thought everything happened with a DHT ?
