Closed source, no thanks. I'm going to follow their approach of "trust no one" and not trust them and warmly recommend everyone to do the same. If you actually mind about security, use GPG.
After the NSA leaks, the security community is scrambling to verify that widely-used, open-source software is free from backdoors. With dual_ec_drbg, we know at least one case where a cryptographic primitive itself was compromised. Furthermore, we know now that governments can and do force companies to compromise their own users, in secret, under gag orders.
Why anyone would use closed-source "security" software today is beyond me.
That... kind of stinks, actually. If your free version doesn't offer the value proposition that makes people excited about your service in the first place, you should perhaps rethink having a free version. It's like giving away popsicles without the stick.
The sender needs a Pro account for the transfer to be secure. If a Pro account sends to a non-Pro account, the transfer will still be secure. More answers at http://wireover.com/faq.
I tried it few months ago and was not impressed. The installer hung on the first run. The app itself crashed. When I tried again in a week they seemed to have a new version and that one actually launched. However it looked completely foreign in Windows as if it were written in Tcl/Tk or some other cross-platform oddity. I clicked through the UI, tried to initiate the file transfer and then gave up. The reason was not that it didn't work, but that it looked as a half-baked product that shouldn't really be let out, even into the beta. You'd expect to find something like this on SourceForge, but not in a form of a commercial security product. It just wasn't trust inspiring :-|
That said I realize that they could've redone the app from scratch in past few months, so take the above for what it is - an impression from a beta.
I use https://www.sharefest.me/ for quick file transfers and it just works with only a web browser. Only downside is Chrome and Firefox don't inter-operate.
Not that sure about level of security, but I have a harder time trusting proprietary software over OSS stuff.
With sharefest I could even run my own service if I wanted to, all the code is on Github.
> How do you make sure the person you are sending the file to is in fact that person and not someone else?
The same way banks do "email money transfers": they email the recipient their pairing token. The logic being, if you can get into X's email, either you are X, or you're acting on their behalf. (And these types of services are used rarely-enough that if X has their email compromised, the sender will have already heard about it.)
> How are keys exchanged?
And this is why I said "pairing token" above--it seems like both clients have to be running at the same time for the transfer to progress, so presumably it's something like an ICE[1]-enabled TLS session between the two computers.
"WireOver uses what we believe are the most appropriate, safe, up-to-date, peer-reviewed crypto primitives, implementations, and parameters [...] Fingerprint Algorithm: MD5"
I fear this page was written with a straight face :(
There's a tradeoff between collision resistance and fingerprint string length. We chose MD5 because people are comfortable with it in ssh, it's a shorter string to verify than something like SHA-256, and because we planned to make your peer's entire public key base64 available if you really wanted to go that extra mile (currently not available).
What would you prefer personally: (1) MD5 fingerprint for convenience AND entire peer public key base64 available if you really want; vs (2) just a longer SHA-256 fingerprint.
I wish they'd explain this "fingerprint" system that secures Diffie-Hellman against the man in the middle. e.g. how are fingerprints exchanged? If you can exchange anything truly securely, you can exchange good old fashioned public keys. If you can't exchange something securely you can't stop MIM attack.
It works like ssh. When you send or receive securely, you can see a fingerprint of your peer's public key, and a fingerprint of your own public key. Your peer sees these too.
To mitigate MITM attacks, ask your peer for their public key fingerprint using something other than WireOver: phone, SMS, email, PGP email - whatever you're comfortable with. That's your "second factor of authentication".
Your approval is cached so you only need to do it once.
So if sending files in the clear is free, whats stopping me from encrypting the files myself and then sending them? Is their value in key exchange, convenience?
Well there is nothing to stop you doing rsync with SSH and having something roughly equivalent to the professional version but try getting someone who isn't an admin or developer to get it set up.
This isn't meant to be negative about this company, it really may be easy for everyone to use and lead to a success.
Congrats on launching! I met Trent briefly a few months ago, but it's clear he has an awesome focus on building a solid, secure product. It seems like it took a while to get this out the door but when your core value prop is security, you can't really cut corners.
Haven't sent a file yet but the download/signup flow was super easy - I was ready to send in about 20 seconds.
Indeed, but they are no more. There’s still a relatively unmet need for sending huge files fast (and free) and for sending with incredibly strong security.
I like their warrant canary for the simple reason that it says "we have received 0 requests from any government agencies to provide any information about any of the following: our users, transfers, code, security architecture, or security credentials."
Although, making a list explicit like that is a creative lawyer challenge to look forward to - I'm not going to ask for something on that list, but I'll ask about something else...
I'm not sure how useful that canary is going to be, though. Secure transfer of large files is a powerful tool for many people, including unsavory types like child porn distributors. I expect and encourage the government to investigate things like that, and those lawful, ethical investigations are going to bump the counter, making a lot of people think "The NSA is all up in our filez!".
I think that's why it's important to pay attention to the President's reforms - as in, see which ones can make actual improvements even if they all can't. Changing the gag order process has the ability to do this b/c you can have, for example, a counter for child porn, a counter for domestic terrorism, a counter for foreign terrorism. Not by providing the service with any confidential files that are part of the case but by making sure some public advocate who does know the type of case can see to it that it's been coded into the gag order appropriately. I'm just spitballing off the top of my head but what argument would they have to not allow a service provider to show that child pornographers should not expect to be safe here - it's win win.
I would advise getting up with someone from rsync, they have had as far as I can tell the longest running warrant canary on their site
I was actually doing some personal research work on the legality of warrant canaries but I've both started a new dayjob and the President announced some changes to NSLs involving gag orders so Ive put that on hiatus for the moment
Thank you, commenters. Your feedback carries weight.
We have a "Friends of WireOver" group that we'll occasionally ask for feedback, advice, and new release testing. Email friends_at_wireover_dot_com to join.
Torrents don't necessarily work behind NAT, especially corporate NAT. (And they never will, because there's really no cost-effective way to provide an M:N equivalent of TURN[1], unless you throw the advantages of peer-to-peer transfer away entirely by creating a hub-and-spoke model.)
