The data going over TURN is always encrypted in WebRTC, so relays can never see what you send (at least in all normal implementations).
The handshake can be sent out-of-bound like you say, but if you are not at the same physical place or have some pre-trusted way to transmit them you always need to trust something.
Even if you send it over something that is previously e2e-encrypted like signal or keybase you always need to trust that channel, so unless you actually are at the same physical place to do the handshake over a non-remote channel or have setup the channel earlier I don't think there is a way to do it "truly securely". The same is true for basically all e2e-encrypted systems that don't have a way to establish an out of bounds channel of trust (like for example the web PKI structure or the debian web of trust).
If you were to use existing web PKI (every participant having their own domain) and require all participants to encrypt with their DV/OV/EV validated keys that might work, but that also seems like a lot of work and cost for messaging and sending files.
Also, I'm not sure what threat model you are mitigating by encrypting the payload on an already e2e-encrypted channel since you load third party JS without SRI, don't have a CSP and don't have HSTS. Basically there are a few steps I'd take before worrying about having a minimal server forwarding the handshake. This seems like you have not considered what the threat model for your service actually is.
I might not just understand the cryptography here, but how does that protect against the server or a third party with access to the handshake to act as a relaying party (basically doing a MITM attack)?
Does it actually not need to trust the server or have any preexisting trust in the other party?
See https://instant.io [0] for a similar file sharing service, but over BitTorrent over WebRTC (not sure if it requires a relay TURN server when peers are behind symmetric NAT) [1][2].
Regarding the TURN server, is that something that is specific to the service? It seems to me that a more general approach would be preferable, i.e. not connected to any particular service.
"Copy secret/index-sample.js to secret/index.js and set the Twilio API key if you want a NAT traversal service (to help peers connect when behind a firewall)."
Are there any open source variants that combines browser p2p and a "permanent" seed server?
I'd like to self-host a solution that let you upload (preferably via webtorrent) and share a file from a browser, but then let the server cache/host the file (preferably with http seeding support) - as well as give you a shareable magic link for classic torrent clients and a http url for browser download.
As far as I can tell, most solution ion are either browser p2p only, or server to browser (download only)?
> I'd like to self-host a solution that let you upload... from a browser, but then let the server cache/host the file... as well as give you a shareable magic link for torrent clients... and a http url for browser download.
Not self-hosting or open-source, but: One could upload objects to S3 and generate a .torrent file to download it from a BitTorrent client or download it via HTTP. Both these features are available at no extra cost (except for the bandwidth, of course).
Unfortunately, S3 has stopped supporting .torrent downloads from newer regions (post 2016). Also, the per-torrent object size is limited to 5GiB, plus enabling public and anonymous access to the torrent-able object is required, which is understandable but might be not feasible for most use-cases.
As much as I'm a fan of these FOSS WebRTC solutions, nothing quite worked for me reliably in a room of people with a variety of devices and technical knowledge.
I use https://fileroom.io/about but it is not FOSS, it does use their own servers for storage (you have to believe they delete the files) and the project looks dead overall.
But this drop.lol thing does not allow "click to browse" and that is rather cumbersome on mobile. Also, users should be able to asign a name?
It's a few things, drop is the word for licorice and lol is the word for fun. It's also one letter off 'droplul' which would be a swear word for asshole, literally: licorice dick.
If you're on the CLI and need to quickly get a file from one machine to another, check out my https://patchbay.pub service. There are now a couple open source implementations that can handle the file sharing case.
27 comments
[ 5.6 ms ] story [ 74.7 ms ] threadIt uses AES encryption to encrypt the contents of the data so that any TURN relays couldn't see the contents of what was being transferred.
The key material between sender/recipient are transferred via the hash-param of the URL, which AFAIK isn't sent to the server and is hidden.
The handshake can be sent out-of-bound like you say, but if you are not at the same physical place or have some pre-trusted way to transmit them you always need to trust something.
Even if you send it over something that is previously e2e-encrypted like signal or keybase you always need to trust that channel, so unless you actually are at the same physical place to do the handshake over a non-remote channel or have setup the channel earlier I don't think there is a way to do it "truly securely". The same is true for basically all e2e-encrypted systems that don't have a way to establish an out of bounds channel of trust (like for example the web PKI structure or the debian web of trust).
If you were to use existing web PKI (every participant having their own domain) and require all participants to encrypt with their DV/OV/EV validated keys that might work, but that also seems like a lot of work and cost for messaging and sending files.
Also, I'm not sure what threat model you are mitigating by encrypting the payload on an already e2e-encrypted channel since you load third party JS without SRI, don't have a CSP and don't have HSTS. Basically there are a few steps I'd take before worrying about having a minimal server forwarding the handshake. This seems like you have not considered what the threat model for your service actually is.
Does it actually not need to trust the server or have any preexisting trust in the other party?
Other such services shared on news.yc previously: https://sharedrop.net, https://file.pizza, wormhole et al [3][4].
Just a reminder that, WebRTC doesn't leak your public-IP if you're behind a VPN [5].
---
[0] https://news.ycombinator.com/item?id=9568939
[1] https://news.ycombinator.com/item?id=19603947
[2] https://tools.ietf.org/html/rfc8445
[3] https://news.ycombinator.com/item?id=17356023
[4] https://news.ycombinator.com/item?id=14649727
[5] https://news.ycombinator.com/item?id=12527956
(Which is somewhat strange given that they are supposed to be run mostly in the browser.)
One reasons services might have shut down is running the TURN server. An added annoyance over what would otherwise just be static files.
Regarding the TURN server, is that something that is specific to the service? It seems to me that a more general approach would be preferable, i.e. not connected to any particular service.
Also, I'm wondering how IPFS is doing these days.
[0] https://news.ycombinator.com/item?id=21439659
https://www.twilio.com/stun-turn
Via https://github.com/webtorrent/instant.io/blob/master/README....
"Copy secret/index-sample.js to secret/index.js and set the Twilio API key if you want a NAT traversal service (to help peers connect when behind a firewall)."
Are there any open source variants that combines browser p2p and a "permanent" seed server?
I'd like to self-host a solution that let you upload (preferably via webtorrent) and share a file from a browser, but then let the server cache/host the file (preferably with http seeding support) - as well as give you a shareable magic link for classic torrent clients and a http url for browser download.
As far as I can tell, most solution ion are either browser p2p only, or server to browser (download only)?
Not self-hosting or open-source, but: One could upload objects to S3 and generate a .torrent file to download it from a BitTorrent client or download it via HTTP. Both these features are available at no extra cost (except for the bandwidth, of course).
Unfortunately, S3 has stopped supporting .torrent downloads from newer regions (post 2016). Also, the per-torrent object size is limited to 5GiB, plus enabling public and anonymous access to the torrent-able object is required, which is understandable but might be not feasible for most use-cases.
https://docs.aws.amazon.com/AmazonS3/latest/dev/S3TorrentRet...
I use https://fileroom.io/about but it is not FOSS, it does use their own servers for storage (you have to believe they delete the files) and the project looks dead overall.
But this drop.lol thing does not allow "click to browse" and that is rather cumbersome on mobile. Also, users should be able to asign a name?
[1] https://github.com/warner/magic-wormhole