Magic-Wormhole – Get things from one computer to another, safely
github.com
github.com
why not make use of https://docs.syncthing.net/users/strelaysrv.html ? lots of servers http://relays.syncthing.net/
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.
_AFAIR Signal has a size limit on the file you can send
_you need a phone number and a smartphone to use Signal
_The Synching key you have to share is complicated, but sending it via email and making sure you add the hosts quickly on both sides would provide enough security guarantees for most people. If you have a secure messenger then you can simply share the key through this channel. And overall I find it easier to explain how to
1) install Signal
2) install Syncthing and share the keys
rather than install magic-wormhole and use some passphrase.
In Signal, the security of the initial message exchange depends upon the phone network (did somebody spoof caller-id to claim Alice's phone number?) and the Signal servers (did they report the correct key for Alice's phone number)? Once you've verified keys in person, those concerns go away. In magic-wormhole, the security of the initial message exchange depends just upon the wormhole code.
For Syncthing, if I remember right, you have to exchange "Device IDs", which are like public keys. You can send them over email, but the security depends upon the email servers (did any of the servers along the path replace that DeviceID with a false one?). The window of opportunity for that attacker is basically the same as it would be for a wormhole code sent via email. And Syncthing gets you long-term/repeated sharing of a folder, whereas magic-wormhole is one-shot.
My goal for magic-wormhole is to offer it as a provisioning protocol for other tools (with better UI and more functionality). Imagine if Syncthing had an "Invite A New Device" button, and pushing it gave you a wormhole code, and the other Syncthing instance had an "Accept Invitation" button where you type in that code. Then you could get all the nice UI and workflow of Syncthing, but you wouldn't have to transcribe the large Device ID (pubkey), and you could do it over something safer than email (like a phone call or just speaking the code to the coworker sitting next to you).
...and upon third-party rendezvous/relay server, doesn't it?
An evil relay server could not send the information, or send information to the wrong server, but neither would cause data to be lost because of the encryption.
P.S.: some have mentioned that using apt to install dependencies and then pip to install Magic-Wormhole itself is complicated. You should probably replace these instructions for Debian by "sudo apt install magic-wormhole", as it is included in Debian as of Stretch (stable). It should be the recommended option anyway.
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.).
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
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.
Python's greatest weakness is its packaging and distribution, and this project makes no effort to make it simple.
brew install magic-wormhole [1]
And that covers 90% of the people that care. Granted I think you're right that software packaging and distribution is still generally broken in 2017, but that's a problem across the board. It's a problem with java, node.js, python, etc.
You probably shouldn't have tried to pad out your steps by taking a detour into package management.
Disagree. I don't know a single non-programmer with brew installed on their Mac, and non-programmers make up 90% of the people who have the most trouble copying files between two computers.
I'm not even sure I see how this is much easier than ssh if you know the basics.
It's been bundled with Python for years now, and even if you don't have it, it's easy to get:
In production when I deploy a django app, now I might have two libraries in different places in my system. One from the OS, and one from the pip dependency.
I'm hoping to get beyond that, once I get the protocol and feature set stabilized. Using something like PyInstaller or py2app to get a single-file executable will be the first step. Porting it to other languages (I've started on SPAKE2 in Rust) might help too.
FWIW, "apt install magic-wormhole" now works on Debian (stretch) and Ubuntu (zesty). Also homebrew, as mentioned before.
Quick survey: what packaged form would be most useful to you (for desktop usage.. having some kind of iOS/Android app is a whole other beast). PPA? .dmg? .exe? .msi?
Specifically, one that 'just works' on windows, and doesn't require that you open powershell and need to change into an obscure directory to use it, or have the binary sit in a folder full of DLLs to run.
In fact, ideally one you don't have to even type anything in; for example, if you can just say; grab this one file from some safe known url (eg. github), and rename it from 'magic.exe' to 'zesty-fruit-324234.exe' and run it.
AirDrop is cool in theory but works about 20% of the time for me. In 2017, the best way to send someone a large file is still to upload it somewhere then give them the link to it. https://getdropsha.re and similar stuff makes that easy enough that your non-technical relatives can use it successfully.
The equivalents to steps 1-11 were done by the Wormhole authors when they created the rendezvous server. So yes, if you use Wormhole in SaaS mode, it's simpler, but you have to trust the rendezvous server.
Operating scp with a working ssh server is as simple as working with wormhole:
To push:
scp foobar.txt tmp@www.example.com: #equivalent to wormhole send
To pull:
scp tmp@www.example.com:foobar.txt . #equivalent to wormhole receive
To revoke access, you simply change the password, instead of deleting the user account. In fact, the steps you mention are what I already have by default on most of my machines, so there's 0% extra effort. I got rssh working in five minutes.
Steps 10/11 are my responsibility, and the only remaining step for the other developer is step 7.
Compare explaining the above two commands to explaining virtualenv and pip. On a busy public IRC channel, I'm not going to do that, I'll use scp, since it's also preinstalled on their system.
So yes, I do rejoice in the simplicity.
I commented for the benefit of those already running ssh, and who wondered how to create a similar setup to wormhole with what they have. rssh will work fine.
Do you? It seems that magic-wormhole does end-to-end encryption, and the rendezvous server acts only as a relay if one or both parties are behind NAT. So yes, you leak the two parties' IP addresses, but not the files you transfer.
It would allow for a "magic wormhole"-style system without the need for a MITM (trusted or otherwise).
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.
I wonder if there is still some opportunity to find workarounds in this space. I did see some papers on prediction of the external ports based on local port and NAT vendor, but this is obviously not going to work for a no-bs-magic-wormhole-style solution.
* 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.
Also see https://github.com/warner/magic-wormhole/issues/48 for some discussion about making things work when you're connected to each other but not to the internet, e.g. an ad-hoc wifi network. It doesn't work at all now, but it totally should.
What I would to see from this is a JS which serves every asset on a site via webtorrent so visitors are sharing the bandwidth costs.
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).
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.
I realize this complicates things a touch - you need a program to encrypt and decrypt the file - but that seems much more secure.
https://www.schneier.com/blog/archives/2011/08/new_attack_on...
Close though :)
This is plenty enough.
Another option is to use the ssh model whereby the sender has a persistent keypair, uses it to sign the handshake and sends the pub key to the peer. If the peer has this key in its key cache, it proceeds quietly. Otherwise it pops up a "New key, please verify and approve" message before proceeding.
The more popular this program gets, the easier it is to steal people's information?
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.
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).
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.
https://github.com/zerotier/toss
... and another less magical one:
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):
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.
I'm hoping to add NAT/UPnP support, but it's not there yet.. still looking for an easy library with Python support.
Eventually I'm planning to have the client ask the transit server ahead of time for the size it intends to use, and the server can tell them to go away or make a donation or something.
"wormhole --transit-helper=tcp:HOST:PORT send" is how you can use a different server: the sender will tell the receiver about it in-band, so the receiver doesn't need to do anything special. The receiver accepts that argument too.
I would probably write it in go to make it easy to compile for different platforms.
$ curl --upload-file ./hello.txt https://transfer.sh/hello.txt
https://transfer.sh/66nb8/hello.txt $ dl-cli some/files
https://dl.example.com/t=<hash>
[1] https://www.thregr.org/~wavexx/software/dl/ [2] https://fex.rus.uni-stuttgart.de/
$ < hello.txt nc termbin.com 9999
http://termbin.com/e51kYes, an attacker can denial-of-service by guessing once on all the (possible) requests. There is some work towards stopping this sort of behavior (see e.g. https://github.com/warner/magic-wormhole/issues/126)
EDIT: was just explained in other comment by meejah, thanks! (https://news.ycombinator.com/item?id=14649727#14650551)
Still cool though :)
* the network-side attacker gets to see and modify all your data * the receiver must have a public IP address * the receiver must tell something to the sender, which is the opposite of the direction the data will flow * you have to transcribe your IP address and port number to the other person, which I always get wrong (so many meaningless numbers!) * you don't get much confirmation that all the data arrived, or that it arrived accurately
The wormhole code uses a wordlist that was carefully designed (not by me.. I'm using the PGP wordlist, as used by PGPfone and Zfone) for accurate spoken transcription in noisy environments. So it's more likely that they'll type in the right thing.
In fact there's a mode (kinda experimental right now) to use magic-wormhole to transfer an ssh pubkey into the ~/.ssh/authorized_keys on a new account. Ideally your site admin should be able to give you access to a new machine with a wormhole code, instead of having you email them a pubkey.
Nice.
Magic-Wormhole: CLI only (so far), no OS integration anywhere, better security properties. Also it's got a spiffy wizard-hat logo (thanks Katie!).
(Also, FTP is an insecure, broken, incomplete, horrible, ancient protocol that should have died in a fire 20 years ago; never mind that I may want to transfer files between two people, not hang those files out onto the web)
"Moving a file to a friend's machine, when the humans can speak to each other (directly) but the computers cannot
Delivering a properly-random password to a new user via the phone
Supplying an SSH public key for future login use"
i had never even thought about those, and this is a great solution afaik
It's public so it can be emailed in cleartext to the admin of the server, copied in any instant messenger or painted on walls. It's the secret key that ensures all the security of the connection.
http://techcrunch.com/2017/06/27/magic-wormhole-is-a-clever-...
Supports Windows (XP and up), OS X/macOS (10.6 and up), Linux (packages for Ububtu and Fedora), and Symbian. Ports available for iOS, Blackberry, and more.
Also, you only need to send the public part of an SSH key to the remote end to set up future keyed connections to that system.
This seems like a solution with very narrow problems to solve.
And S/MIME is essentially PGP/GPG, except you bootstrap the key from a central Certificate Authority. So yes, it's still a hassle.
As for SSH, how would /you/ place the public key on /their/ remote end? That's a bit of a chicken and the egg problem right there, don't you think?
Why not email the ssh public key in plaintext and verify the md5sum, sha1sum, fingerprint, and / or first and last X characters of the key itself over the phone?
... or... Why not just put the public key on a web server with SSL and a free cert and speak the URL, then scp the payload file over? Or go ahead and get the free S/MIME cert from Comodo for your email since you can sign without the other end sending a signed email first and attach the payload file itself or an ssh public key and then scp? Or use Pidgin or a similar client with the OTR plugin on any XMPP server and send the payload file in the first place? Or issue SSL keys from your own local CA and communicate the fingerprint orally? Or send the public ssh key plaintext and only allow ssh through the firewall from the IP of your friend?
... or ... allow ssh via password rather than key for a small timeframe and communicate a password out of band rather than a shared secret for this thing?
... or ... put your ssh public key on a well-known account of yours like GitHub, Facebook, HN, etc and let your friend install it from there?
And for the rest, they're still a hassle compared to just having your hackerspace friend install magic-wormhole so you can toy around with the nonsense he has on his Raspberry Pi.
Your last point, however, I think will be the key to the future (no pun intended). I'm hoping asymmetric crypto based communication will become easy, ubiquitous, and the default. Cheers to Keybase!