Hacker News Reader

Comment by StavrosK | Hacker News Reader

I submitted a feature request for encryption over this (it's probably vulnerable to MITM attacks as-is, as you never verify the recipient). My request was:

* Generate the URL like sharefest.me/roomid#randomstring

* Sharefest encrypts the file contents before and after transmission with randomstring as key using the SJCL.

* Send the URL/key out of band, over a secure channel.

* Voila, end-to-end crypto.

I don't know if anything became of it, though.

EDIT: Oh, here it is: https://github.com/Peer5/ShareFest/issues/24

View on HN

Yea you're right, we just didn't get around to it yet. Thanks for the issue.

You are quite welcome, hopefully you'll find some time soon, it would make Sharefest the file transfer mode of choice for paranoid people like me :)

Out of interest, if the decryption is being done in a client by JavaScript, what's stopping a MITM attacker replacing the JavaScript crypto library with something that captures the source URL and key?

That's a well-known problem with JavaScript crypto: http://www.matasano.com/articles/javascript-cryptography/

The short answer is that so long as the page is loaded entirely over TLS, and the TLS isn't stripped or subverted in any way, it's safe from MITM. Sharefest doesn't currently support TLS, so they would need to set that up prior to enabling end-to-end encryption.

The P2P crypto is done by the browser. But not doubt that we need to load the entire page and scripts securely securely...

Nothing (assuming the MITM is someone who can break HTTPS or Peer5 themselves), which is why I proposed this:

https://github.com/Peer5/ShareFest/issues/30#issuecomment-20...

You can download ShareFest, audit it and store it locally so you can run your known-good version. It's just an HTML page and a few JS files (or at least it was, last time I looked).

I was going to create a version of this that was a single webpage and had as little code as possible (for auditability and ease of saving/deployment), but other projects got in the way (plus it's easier to improve ShareFest than write it from scratch).

It's clearly not baseless paranoia anymore.

That's true, I guess. The funny thing is that the most I ever transfer is family photos and code, but I don't see why anyone should be able to look at even my family photos.

The other thing is, as with almost all web-based solutions, you're being tracked by various scripts in the background (Google API/JS, etc.). So, if you're paranoid, you're better off with a client solution.

Client side solutions can do even more tracking because there is no browser sandbox. And for example the µTorrent client has ads in it which are probably tracked.

Yes, I suggest using open-source clients that don't include ads (such as RetroShare). µTorrent is not open-source, btw.

So if the issue is tracking regardless, why not use a non-tracking web app?

Sure, but a client solution doesn't have the ease-of-use of this for the other party. I use Ghostery, incidentally, but your general point is that security on a live webpage is impossible, which I agree with. That's why I proposed that the app be made into a downloadable package as well.

It would be interesting to create a self sustained WebRTC client that can communicate with the web version.

It already can, the web version is just an HTML file with some JS too.

Personally, I don't see a better platform than RetroShare. That is why I believe, we're better off if we all get behind RetroShare:

Developers can extend this platform with as many plugins as they wish - as an open-source solution, it's totally open. (I believe fragmentation, more specifically increasing the number of less advanced solutions doesn't help...)

Why downloadable package is necessarily more secure than a live webpage over TLS (HTTPS)? Given that you can verify that Sharefest is Sharefest (using the certificate in the future), I don't see the big difference. I do think that a live webpage can be updated with security fixes more easily.

Being a live webpage also give us, as the developers, much less headaches in terms of protocol compatibility -- We maintain just one "version" of Sharefest client at the same time.

Because a downloadable package can't be replaced by something else the next time you use it, while Sharefest can, and nation-states can easily serve you whatever they want, even over SSL.

But nation-states can do that for downloadable packages as well, perhaps even the verifiers for those packages...

How?

They can spoof the package and its key. If the root of trust (CA) is tempered as you suggest and the chain of trust is broken, I don't see how you can really secure it.

Reply on news.ycombinator.com