> The wormhole library requires a "Rendezvous Server": a simple WebSocket-based relay that delivers messages from one client to another. This allows the wormhole codes to omit IP addresses and port numbers. The URL of a public server is baked into the library for use as a default, and will be freely available until volume or abuse makes it infeasible to support.
Interesting.. I'll take a look at it. My first thought is that magic-wormhole needs a canonical way to allocate "nameplates" (the numeric channel identifier at the start of the wormhole code), and that's tricky to do in a DHT (I'm assuming syncthing's relay server behaves like a DHT).
You can also use https://ondevice.io for that. But in that case it let's you ssh into the remote device even if it changes location/ip-address.
I use it for some IoT tinkering I do.
> Copying files with ssh/scp is fine, but requires previous arrangements and an account on the target machine, and how do you bootstrap the account?~
Assuming that you have openssh and rssh installed, you bootstrap like this:
useradd -m -g users -s /usr/bin/rssh tmp
passwd tmp
edit /etc/rssh.conf and uncomment allowscp
Share the password with the party you want to exchange data with. Make sure your ports are open.
The use case I see for wormhole is if you're working purely in the python ecosystem. That's it.
You're free to disagree of course, but I prefer ssh, since it's peer-to-peer end-to-end encrypted,
and extends to cover other use cases much more easily (rsync, VNC, etc.).
When both parties are in a corp network (eg across companies) you would need a server anyway. Many either offer a FTP server or have switched to Accellion (which is kinda cr.p, and full of security holes)... so this is a nice, fast and secure alternative.
Surprised no-one has mentioned socat ('netcat on steroids') in this context, which is what I use to quickly transfer files, especially in closed network contexts.
Both pwnat and chownat are very clever techniques, but I have massive doubts they work _well_ in practice, when exposed to hundreds (or even dozens) of popular NAT devices and network configurations.
Vast majority of NAT boxes change the source port on outbound packets even if a respective externally-facing port is not yet allocated. Anything that's BSD derived will randomize the port, lots and lots of others will +1 the port for each new session, thirds will +2 the port, etc.
There's also egress filtering, intrusion detection systems and NAT devices that do things that make little sense such as remapping ID field in the IP header, presumably for security reasons. Also, depending on the OS, this will need root privileges to craft fake ICMP packets.
All in all, pwnat/chownat are essentially very cool "tech demos" that can't be realistically used just on their own and require a conventional rendezvous server as a fallback.
Nifty.. I'll look at the network side of that, maybe we can steal some ideas. At the moment magic-wormhole depends upon one of:
* at least one side has a public IP address
* both sides are on the same (private) LAN
* a TURN-like "Transit Relay" server that I run
That transit server hasn't gotten a worrysome amount of traffic yet, but it's a potential scaling problem. (Fortunately the two sides can offer their own transit servers, and they negotiate the one to use, so it's also not a difficult scaling problem to address).
In the long run I'm hoping to get some NAT-hole-punching tools, maybe WebRTC, to reduce the need for the transit relay somewhat. Also in the long run, if both sides are using Tor, then one of then can run an onion service, which gets you the NAT-punching for free.
The security model here is pretty great assuming you trust the rendezvous server.
Maybe consider an optional challenge/response prompt (like when your pal enters the prompt code, their client generates a second code that they give back to you) to make sure nobody's intercepted the request before them, odds aside (if someone got your initial code somehow, they could definitely man in the middle the request otherwise).
If I did things right, the rendezvous server shouldn't get any advantage over a network attacker: one guess per invocation of the program, 1-out-of-65536 chance of getting it right, 65535-out-of-65536 chance of giving you a WrongPasswordError.
FWIW, there's also a --verify option, which causes the program to print out a hex hash of the session key, and wait for you to approve it before sending anything. Not as ergonomic, but it removes the MitM threat pretty effectively.
Eh,I like the concept of kbfs and have it installed on my PC and phone, but it's not really a competitor to this. Keybase reminds me of a secure alternative to Dropbox or Google drive. You've got a quota that you can upload to their server (encrypted). While you can use it to move files between destinations, that isn't it's primary goal.
And it's not a lossless storage at that, as their filesystem doesn't support all metadata . I.e. it removes any timestamps from the files.
I would use this just to cut and paste text from my host machine to my VMs, because I've never been able to get that seemingly simple concept to work reliably.
I see you guys arguing what is easier, wormhole, syncthing, ssh. I'll argue that Keybase is by far the easiest. Just but the files in /Keybase/private/person0,person2
I love Keybase.. they're doing great things to bind public keys to names at large identity providers (twitter, github, etc). And in many cases, the github username of your intended recipient is the only thing you know about them anyways.
magic-wormhole can help you in the case where you're sitting next to someone at a conference and they don't have a github/twitter account, or if you want don't want to depend on github/twitter/etc access control (e.g. if some bug in github allowed gists to be published under other people's usernames, that aspect of the keybase security story would fail).
It might also appeal to folks who don't care for centralized identity providers. When we worked on Mozilla Persona, we tried to make it possible for individuals to run their own IdPs and "own your own identity". Keybase can sorta do that (by proving ownership of an HTTP or HTTPS URL), but magic-wormhole is "better" in the sense that it doesn't have any concept of identity at all. The file goes-to/comes-from the person who knew the same code, end of story.
I'm interested in some sort of combination: maybe a confirmation step that uses a wormhole code to exchange the expected public keys with a Keybase peer, to make sure they're the same, without needing to type or read the full RSA key. (There's a protocol named SAS, "Short Authenticated Strings", that can be useful in this case).
> Copying files onto a USB stick requires physical proximity, and is uncomfortable for transferring long-term secrets because flash memory is hard to erase. Copying files with ssh/scp is fine, but requires previous arrangements and an account on the target machine, and how do you bootstrap the account? Copying files through email first requires transcribing an email address in the opposite direction
I had similar motivations in 2006 to write a tool to copy files "point to point". So here's my shameless plug:
(they use a few other scripts from the same repo) used like follows (only practical when being able to copy-paste, my use case is to copy things between servers without needing ssh authentication between them, but having open ssh sessions into both from the same desktop/laptop):
chris@a:/tmp/chris$ echo Hello > World
chris@a:/tmp/chris$ netoffer World
--Run:--
echo jxqtrb7xfq2e4dqy3uitc7986ydj56w59iqu84b | netfetch 78.47.51.206 15123
chris@b:/tmp/chris$ echo jxqtrb7xfq2e4dqy3uitc7986ydj56w59iqu84b | netfetch 78.47.51.206 15123
chris@b:/tmp/chris$ cat World
Hello
It also allows you to share any data but also deals with incremental updates. The main use-case is to share big scientific datasets that update over time.
Nice! It might be interesting to use the magic-wormhole API to set up the piknik keys. In the long term, I'm pushing magic-wormhole to serve as a provisioning tool for other (more persistent) connections.
https://transfer.sh/ is another neat service which allows you to upload a file easily using a tool such as curl and get a shareable link. There was one time when I only had Chrome Remote Desktop access to a machine without root, where this was a convenient way to share some files.
additionally, the file is automatically cleared when it goes unused for a while. There is also FEX[2], which is geared more towards power-users and includes bi-directional transfers. Both are fully self-hosted and trivial to set-up.
[+] [-] ohhhlol|8 years ago|reply
why not make use of https://docs.syncthing.net/users/strelaysrv.html ? lots of servers http://relays.syncthing.net/
[+] [-] lotharrr|8 years ago|reply
We've got a ticket open (https://github.com/warner/magic-wormhole/issues/72) about distributing this rendezvous server.. I'll add a note to check out syncthing.
[+] [-] BrandiATMuhkuh|8 years ago|reply
[+] [-] bhenc|8 years ago|reply
Assuming that you have openssh and rssh installed, you bootstrap like this: useradd -m -g users -s /usr/bin/rssh tmp passwd tmp edit /etc/rssh.conf and uncomment allowscp Share the password with the party you want to exchange data with. Make sure your ports are open.
See: https://serverfault.com/questions/197545/can-non-login-accou...
The use case I see for wormhole is if you're working purely in the python ecosystem. That's it.
You're free to disagree of course, but I prefer ssh, since it's peer-to-peer end-to-end encrypted, and extends to cover other use cases much more easily (rsync, VNC, etc.).
[+] [-] bb88|8 years ago|reply
Step 1. Open ports on your router. It's your job to figure out which ports those may be.
Step 2. Redirect said ports to the box in question, hopefully you'll know the ip address that was assigned by your home router's DHCP
Step 3. Make sure rssh is installed.
Step 4. If rssh is not installed, please simply follow the simple instructions to get it installed for your system.
Step 4a. If it's a mac, use brew. Type brew install rssh
Step 4b. If it'a a redhat system, type yum install rssh
Step 4c. If it's an ubuntu system, type apt-get install rssh
Step 4d. If step 4b and step 4c fail, use sudo.
Step 5. Get the external facing ip address, and give it to your friend. Note that this is different than the internal address that you used in step 2.
Step 6. Create an account on your system, using rssh, and allowing sftp
Step 7. Give him the username/password
Step 8. Copy the file into his account
Step 8a. Don't forget to chmod it so he can read it.
Step 9. Tell him to get the file
Step 10. Remove the account from /etc/passwd and /etc/shadow and remove him from /etc/groups. Also delete his home directory
Step 11. Rejoice in the simplicity.
[+] [-] dmd|8 years ago|reply
Ah, yes. oh come on please it's easy just /etc/init.apt-get/frob-set-conf --arc=0 - +/lib/syn.${SETDCONPATH}.so.4.2 even my grandma can do that
[+] [-] mschuster91|8 years ago|reply
[+] [-] zwischenzug|8 years ago|reply
[+] [-] penetrarthur|8 years ago|reply
[+] [-] d0mine|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] bob1029|8 years ago|reply
It would allow for a "magic wormhole"-style system without the need for a MITM (trusted or otherwise).
[+] [-] huhtenberg|8 years ago|reply
Vast majority of NAT boxes change the source port on outbound packets even if a respective externally-facing port is not yet allocated. Anything that's BSD derived will randomize the port, lots and lots of others will +1 the port for each new session, thirds will +2 the port, etc.
There's also egress filtering, intrusion detection systems and NAT devices that do things that make little sense such as remapping ID field in the IP header, presumably for security reasons. Also, depending on the OS, this will need root privileges to craft fake ICMP packets.
All in all, pwnat/chownat are essentially very cool "tech demos" that can't be realistically used just on their own and require a conventional rendezvous server as a fallback.
[+] [-] Animats|8 years ago|reply
[+] [-] voltagex_|8 years ago|reply
[+] [-] schoen|8 years ago|reply
[+] [-] lotharrr|8 years ago|reply
* at least one side has a public IP address * both sides are on the same (private) LAN * a TURN-like "Transit Relay" server that I run
That transit server hasn't gotten a worrysome amount of traffic yet, but it's a potential scaling problem. (Fortunately the two sides can offer their own transit servers, and they negotiate the one to use, so it's also not a difficult scaling problem to address).
In the long run I'm hoping to get some NAT-hole-punching tools, maybe WebRTC, to reduce the need for the transit relay somewhat. Also in the long run, if both sides are using Tor, then one of then can run an onion service, which gets you the NAT-punching for free.
[+] [-] lima|8 years ago|reply
[+] [-] chx|8 years ago|reply
[+] [-] d4l3k|8 years ago|reply
[+] [-] pscsbs|8 years ago|reply
[+] [-] fiatjaf|8 years ago|reply
[+] [-] allworknoplay|8 years ago|reply
Maybe consider an optional challenge/response prompt (like when your pal enters the prompt code, their client generates a second code that they give back to you) to make sure nobody's intercepted the request before them, odds aside (if someone got your initial code somehow, they could definitely man in the middle the request otherwise).
[+] [-] lotharrr|8 years ago|reply
FWIW, there's also a --verify option, which causes the program to print out a hex hash of the session key, and wait for you to approve it before sending anything. Not as ergonomic, but it removes the MitM threat pretty effectively.
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] sw1sh|8 years ago|reply
[+] [-] y4mi|8 years ago|reply
And it's not a lossless storage at that, as their filesystem doesn't support all metadata . I.e. it removes any timestamps from the files.
[+] [-] nsxwolf|8 years ago|reply
[+] [-] rplnt|8 years ago|reply
[+] [-] nattmat|8 years ago|reply
[+] [-] lotharrr|8 years ago|reply
magic-wormhole can help you in the case where you're sitting next to someone at a conference and they don't have a github/twitter account, or if you want don't want to depend on github/twitter/etc access control (e.g. if some bug in github allowed gists to be published under other people's usernames, that aspect of the keybase security story would fail).
It might also appeal to folks who don't care for centralized identity providers. When we worked on Mozilla Persona, we tried to make it possible for individuals to run their own IdPs and "own your own identity". Keybase can sorta do that (by proving ownership of an HTTP or HTTPS URL), but magic-wormhole is "better" in the sense that it doesn't have any concept of identity at all. The file goes-to/comes-from the person who knew the same code, end of story.
I'm interested in some sort of combination: maybe a confirmation step that uses a wormhole code to exchange the expected public keys with a Keybase peer, to make sure they're the same, without needing to type or read the full RSA key. (There's a protocol named SAS, "Short Authenticated Strings", that can be useful in this case).
[+] [-] etanol|8 years ago|reply
I had similar motivations in 2006 to write a tool to copy files "point to point". So here's my shameless plug:
https://bitbucket.org/etanol/canute
In my case, cryptography was not a requirement, though.
[+] [-] llamataboot|8 years ago|reply
[+] [-] api|8 years ago|reply
https://github.com/zerotier/toss
... and another less magical one:
http://www.fefe.de/ncp/
[+] [-] pflanze|8 years ago|reply
https://github.com/pflanze/chj-bin/blob/master/netoffer https://github.com/pflanze/chj-bin/blob/master/netfetch
(they use a few other scripts from the same repo) used like follows (only practical when being able to copy-paste, my use case is to copy things between servers without needing ssh authentication between them, but having open ssh sessions into both from the same desktop/laptop):
(Uses gpg symmetric encryption underneath.)[+] [-] zimbatm|8 years ago|reply
It also allows you to share any data but also deals with incremental updates. The main use-case is to share big scientific datasets that update over time.
[+] [-] jedisct1|8 years ago|reply
[+] [-] lotharrr|8 years ago|reply
[+] [-] Sphax|8 years ago|reply
[+] [-] kyberias|8 years ago|reply
[+] [-] aluhut|8 years ago|reply
[+] [-] grizzles|8 years ago|reply
[+] [-] jbergens|8 years ago|reply
I would probably write it in go to make it easy to compile for different platforms.
[+] [-] pveierland|8 years ago|reply
[+] [-] usernam|8 years ago|reply
[1] https://www.thregr.org/~wavexx/software/dl/ [2] https://fex.rus.uni-stuttgart.de/
[+] [-] Arkanosis|8 years ago|reply
[+] [-] niutech|8 years ago|reply
https://send-anywhere.com
https://takeafile.com
https://www.justbeamit.com
https://www.sharedrop.io
https://www.reep.io