Show HN: Peer-to-peer secure file transfer using WebRTC
bitf.lySimilar project: FilePizza – https://file.pizza/
github: https://github.com/kern/filepizza show hn: https://news.ycombinator.com/item?id=9535332
Reminds me that i ran into a blog after the referenced comic was publish, that mused about how the trouble of easily sending files between PC online was a conspiracy between the ISPs and the *AAs.
The URL references the ID number of this comic: http://xkcd.com/949/
cat $FILE | nc -l -p 80firewalls?
The limitation of this method is that you do need your own port exposed to the internet. The advantage of this method is that you don't have to trust a third party.
For the explicit example above, your guest's firewall would have to be pretty brutal to not allow port 80 through.
Yeah it was mostly the senders firewall (or the NAT you find on most consumer routers) that i had in mind.
The OS may also balk at opening such a low port as a user, now that i think about it.
ipv6
Does anyone know how FilePizza and Bitfly compares to WebTorrent?
WebTorrent actually implements the bittorrent protocol, and can be used as a nodejs bittorent client. It extends the bittorent protocol to do p2p sharing inside the browser (but you only can connect to other people using the webtorrent nodejs app or in-browser app, and not all the bittorent network)
FilePizza and Bitfly are much simpler implementations, doing 1-to-1 file transfers in the browser using the basic WebRTC Datachannel API.
Looks like FilePizza is now using WebTorrent too now, as it's mentionned in their FAQ:
"Where are my files sent? Your files never touch our server. Instead, they are sent directly from the uploader's browser to the downloader's browser using WebTorrent and WebRTC. This requires that the uploader leave their browser window open until the transfer is complete."
Happy to see that it works with CyanogenMod Chrome Beta on an old HP TouchPad.
ps: although it says the HTTPS connection is not safe.. weird. pps: lazy me would love a multiple file options ..
From the HN title: "secure"
I have a question: Secure against what thread model?
The FAQ has an entry for "How do I know you're not sending all my data to the NSA?" but that's the wrong question to ask (i.e. Even if you're not behaving maliciously, that doesn't mean our data is safe against highly sophisticated threats).
It would really be great if you could demonstrate what makes this more secure than alternative solutions.
That said, this is kind of neat.
Webrtc itself requires perfect forward secrecy. While you cannot do authentication with it - you need to provide that yourself - you can be certain besides yourself and whomever your signaling server told you is your peer are the only two able to decrypt the packets going between you two.
Doesn't the server know the token id? I didn't inspect the requests, but it's possible to send the token to the server.
Therefore, can't they download the sample just like the connected client?
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 over a server because there is no way to show it is not just being stored on a server.
Not knowing enough about this, I am genuinely curious if something like zerodb solves this. It was posted yesterday, but it was started by 2 guys, i think one was from morgan stanely, that allow you to securely send and receive data from the db while it is portected in flight. Would this be helpful in the scenario?
This will betray my lack of domain knowledge but it sort of opperates like a double encryption, so basically the data is encrypted maybe then sent, then it is encrypted by a forwarding proxy which also has a priv./pub key. You query for the hash, get the hash, decrypt it, and send it back.
Could you use this as the broker for webrtc? I know that wasn't exactly Nakomoto's BitcoinD paper, but their model seems to make sense, and a lot in this context.
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.
This is incorrect. Once data starts to flow, DTLS is used to encrypt the connection and verify each peer's identity. If the STUN server attempts to MITM, it will be detected.
Maybe I'm reading your comment wrong (if so, sorry!), but that sounds like a race condition to me.
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?
You can't trust IP addresses for anything. A MITM-ing wifi router can and will pretend to be "all the IP addresses".
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 every server) then they use that server to exchange NAT-busting messages
Ideally, you would have a lot of different use cases using the same network in such a way that it is hard for a server to figure out what you are using it for, and it is essentially impossible for a server to target MITM a specific pair. What this does leave open is sybil attacking and MITM-ing everything opportunistically. At this point we essentially start to build TOR via websockets and WebRTC and it all breaks down.
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?
that might work well.
I'm a little worried, that because the browser get it's own address from the server there might be a way to build a lie that looks plausible to both users, but I can't think of a way to do that off the top of my head.
> I believe that adding any real crypto to the JS code to be a doomed path
Mega[1] users JS based crypto and it's been fine
[1]: http://mega.co.nz
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.
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.
The server can silently decide to start sniffing the keys at any time. That isn't security.
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
You can trivially ensure that by just downloading the page. These things are usually a single HTML page you can run locally.
I also made a similar project to this using WebRTC: https://www.mkstream.club/#/
Might be just me, but "look I made something similar here is the link" without any more info or mention of how it's relevant sounds a lot like piggybacking off of the success of this thread to promote your own project.
I'm sorry. that wasn't my intent. I just thought that I'd link it for anyone who wants to see another example of a filesharing app made with WebRTC.
Don't worry, this is how HN works and we are able to discover different programs around a similar theme.
There's also http://sharedrop.io, which was featured on HN a couple years ago and also uses WebRTC.
Source: https://github.com/cowbell/sharedrop Discussion: https://news.ycombinator.com/item?id=7468328
fipelines.org is another one (their cert is expired but if you ignore that the site works well)
Yet another is instant.io
"Secure" but "we advise against using Bitfly for highly sensitive data. You have been warned.".
So is it secure or isn't it?
I trust my browser's developers with my most sensitive data (online banking password, government id etc.) but that does not mean I believe I am fully secure in doing so. There could always be a bug in the WebRTC implementation or the SSL library or the hardware. Maybe I should rephrase the FAQ to read "Don't put your highly sensitive data on the Internet at all".
The warning is posted under the headline "How do I know you're not sending my data to the NSA" and in that context, it is a good warning. Don't trust random software with highly sensitive data.
My favorite of these tools is magic womhole (command-line only):
https://github.com/warner/magic-wormhole
It gives you a few words for you to give the recipient, they type them in, and boom, transfer starts.
Sorry for off-topic, does anyone know why Google phone calling (Voice / Hangouts) still doesn't work with WebRTC and requires native plugin? And are there any other services for making phone calls which actually work with WebRTC?
They use nonstandard APIs, and send data over the network in a way incompatible with WebRTC. This post is a bit old at this point but afaik the situation hasn't changed: https://webrtchacks.com/hangout-analysis-philipp-hancke/
Thanks! What a mess. No wonder it's not working for me - I'm using Firefox. Somehow I doubt Google are interested in fixing this.
Appear.in
Can it make calls to real phone numbers, especially between countries? That's essentially what I need. Google provides that, but it works very poorly and requires a native plugin.
For regular Internet to Internet media calls I can use XMPP/Jingle client.
With some sort of peer discovery functionality, this could be a pretty cool open, cross-platform replacement for Apple's AirDrop.
...but would probably need WebRTC functionality in Safari to work on iOS devices
I was thinking this exact use case last in year in some experiments but just got to busy to finish it. I had auto discovery of local computers and a nice name: browserdrop.it.
I had it working too casting a chromecast with a system for displaying various file formats and basically file sharing your phone.
Not enough time in the world to finish every side project. Also once I found out about AirDroid I kind of felt they had my main use case pretty covered. Not quite but close. https://www.airdroid.com/
I mentioned it in another comment upthread, but http://sharedrop.io is exactly this. WebRTC file transfer with LAN peer discovery.
Nice! Right, I forgot I had come across that one too. Using firebase was clever too.
Very cool! We built something similar using flash and RTMFP back in 2010 and actually got into YC W11 with the project (with dreams of building something like airdrop until Apple went and actually built airdrop causing us to pivot into high speed data transport instead).
It's great to see this being implemented using WebRTC now, which was just popping onto the radar back then. I envy you building this without having to write any action script or flex code! Best of luck with the project.
Awesome, I'm looking to incorporate some of this into a project I'm working on.
Slightly off topic, but can anyone recommend a webrtc tutorial for data channels or any projects which can be used for player v player over the browser (chrome) . I guess like one player has to be the master and the other players join his/her webrtc connection ?
I was wondering if it is possible to transfer streaming video data over WebRTC already, for example to implement a video chat service, without wasting too much CPU power and/or bandwidth?
Icecomm lets you use Webrtc to do this pretty easily (icecomm.io)
Interesting. Are they doing image processing / compression in javascript?
Why not just use http://instant.io ?
If you are worried about security, encrypt before sending.
Wow. Now implement this with file search and you've basically got something like Napster.