Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Peer-to-peer secure file transfer using WebRTC

bitf.ly

Post reply on HN
Print view View original

41–50 of 65 posts

Re: Show HN: Peer-to-peer secure file transfer using WebRTC

#41

Post by StavrosK »

Rhapso wrote: post #7
nlightcho wrote: post #6

Earlier quoted context omitted.

Thank you for the feedback! I will change the wording of that FAQ question (+ answer) and make it more detailed. I'm not sure about how I should go about demonstrating what makes this model more secure, except making it more obvious that it doesn't involve storing your data on servers not under your control which is the case with solutions like email and skype.

A big problem is that webRTC is highly MITM-able. You have to exchange initial connections using a server. So no party has any way of knowing if you are MITM attacking. You might be able to do something diffie-helman shaped at the javascript level (hard to ensure it actually works) to show a fingerprint of the shared secret that could be confirmed via outside channels. But all-in-all this does not offer ANY security…

Just encrypt the data and pass the key in the url, like so:

https://bitf.ly/1b4b7ee4fe39312afbfffbe47d831f99#someaeskey

That way, the server never sees the key (it's client-side and fragments don't get sent), but nobody except the recipient can decrypt the data.

Re: Show HN: Peer-to-peer secure file transfer using WebRTC

#42

Post by irascible »

nlightcho wrote: post #10
Rhapso wrote: post #7

Earlier quoted context omitted.

A big problem is that webRTC is highly MITM-able. You have to exchange initial connections using a server. So no party has any way of knowing if you are MITM attacking. You might be able to do something diffie-helman shaped at the javascript level (hard to ensure it actually works) to show a fingerprint of the shared secret that could be confirmed via outside channels. But all-in-all this does not offer ANY security…

These are very good points. I believe that adding any real crypto to the JS code to be a doomed path so I probably won't go for that. My only argument right now is couldn't one verify that the IP of the recipient is the same as the address of the expected receiving device (or router) and be somewhat sure it's not MITM?

Don't hate on js. It is beneath you.

Re: Show HN: Peer-to-peer secure file transfer using WebRTC

#44

Post by Rhapso »

m00dy wrote: post #36
Rhapso wrote: post #7

Earlier quoted context omitted.

A big problem is that webRTC is highly MITM-able. You have to exchange initial connections using a server. So no party has any way of knowing if you are MITM attacking. You might be able to do something diffie-helman shaped at the javascript level (hard to ensure it actually works) to show a fingerprint of the shared secret that could be confirmed via outside channels. But all-in-all this does not offer ANY security…

You can do without using a server. https://github.com/cjb/serverless-webrtc

"A STUN server is still used to find out your external IP for NAT-busting."

essentially, now the STUN is the MITM. STUN server lies to both parties about what their IP addresses are and responds with IPs that it controls. Both parties connect to those IPs and the messages are relayed between them.

Re: Show HN: Peer-to-peer secure file transfer using WebRTC

#45

Post by Rhapso »

StavrosK wrote: post #41
Rhapso wrote: post #7

Earlier quoted context omitted.

A big problem is that webRTC is highly MITM-able. You have to exchange initial connections using a server. So no party has any way of knowing if you are MITM attacking. You might be able to do something diffie-helman shaped at the javascript level (hard to ensure it actually works) to show a fingerprint of the shared secret that could be confirmed via outside channels. But all-in-all this does not offer ANY security…

Just encrypt the data and pass the key in the url, like so: https://bitf.ly/1b4b7ee4fe39312afbfffbe47d831f99#someaeskey That way, the server never sees the key (it's client-side and fragments don't get sent), but nobody except the recipient can decrypt the data.

that only works if you have a way to assure the JS has not being modified every time the page is ever loaded everywhere. That only works on a content addressed protocol like IPFS

Re: Show HN: Peer-to-peer secure file transfer using WebRTC

#46

Post by sneak »

StavrosK wrote: post #41
Rhapso wrote: post #7

Earlier quoted context omitted.

A big problem is that webRTC is highly MITM-able. You have to exchange initial connections using a server. So no party has any way of knowing if you are MITM attacking. You might be able to do something diffie-helman shaped at the javascript level (hard to ensure it actually works) to show a fingerprint of the shared secret that could be confirmed via outside channels. But all-in-all this does not offer ANY security…

Just encrypt the data and pass the key in the url, like so: https://bitf.ly/1b4b7ee4fe39312afbfffbe47d831f99#someaeskey That way, the server never sees the key (it's client-side and fragments don't get sent), but nobody except the recipient can decrypt the data.

The server can silently decide to start sniffing the keys at any time. That isn't security.

Re: Show HN: Peer-to-peer secure file transfer using WebRTC

#47

Post by sneak »

irascible wrote: post #42
nlightcho wrote: post #10

Earlier quoted context omitted.

These are very good points. I believe that adding any real crypto to the JS code to be a doomed path so I probably won't go for that. My only argument right now is couldn't one verify that the IP of the recipient is the same as the address of the expected receiving device (or router) and be somewhat sure it's not MITM?

Don't hate on js. It is beneath you.

Hating on js and acknowledging that it is currently technically impossible to do any real, secure in-browser crypto engineering with it are two different things.

There are no "good parts" to js browser crypto.

Re: Show HN: Peer-to-peer secure file transfer using WebRTC

#48

Post by somidscr21 »

nlightcho wrote: post #23
Rhapso wrote: post #16

Earlier quoted context omitted.

The way I would make this work: - Build a DHT style overlay network of "meet in the middle" servers - Have a standalone html file, that uses websockets to connect to the network of servers. - Have both clients generate keys, exchange them via other channels. - Both users have a shared key, they both lookup the server that hosts the shared key on the DHT network (that actually can be done without leaking the key to ev…

This sounds incredibly complicated :) I would definitely use TOR if I believe I'm facing a dedicated and sophisticated threat. For now I have tried to clarify the issues in the FAQ and can only hope that people read it and don't get screwed over by wrong expectations.

How is Tor supposed to help you defend against MitM?

Re: Show HN: Peer-to-peer secure file transfer using WebRTC

#49

Post by STRML »

StavrosK wrote: post #41
Rhapso wrote: post #7

Earlier quoted context omitted.

A big problem is that webRTC is highly MITM-able. You have to exchange initial connections using a server. So no party has any way of knowing if you are MITM attacking. You might be able to do something diffie-helman shaped at the javascript level (hard to ensure it actually works) to show a fingerprint of the shared secret that could be confirmed via outside channels. But all-in-all this does not offer ANY security…

Just encrypt the data and pass the key in the url, like so: https://bitf.ly/1b4b7ee4fe39312afbfffbe47d831f99#someaeskey That way, the server never sees the key (it's client-side and fragments don't get sent), but nobody except the recipient can decrypt the data.

We do this on securesha.re. Yes, you can't be sure the client hasn't changed the JS - I'm going to start putting md5s in the script tags but it's up to the client to check they haven't changed. However, the client is open source [1], so you could always run your own client.

1. https://github.com/STRML/securesha.re-client/

Post reply on HN