

Free App Lets the Next Snowden Send Big Files Securely and Anonymously - sequoia
http://www.wired.com/2014/05/onionshare/

======
rdl
Sending big files (inherently an asynchronous thing) through a small network
which is inherently connection oriented seems like a bad idea. It is a useful
tool based on what components are available right now, but this is the wrong
way to do things overall for security.

Both of the users have to be online simultaneously; both will be
sending/receiving roughly the same amounts of data at roughly the same time.

If the user is under observation already (due to suspicion, or due to being on
a logged network), and the recipient is already under monitoring (a safe
assumption if he's a well known journalist writing about NSA, or Wikileaks, or
whatever), it's pretty easy to correlate the flows, then find/fix/finish.

The less insane way to do this is to publish an encrypted file to some pool
(usenet, youtube, etc.) using whatever anonymity technology is available to
you, and then at some point in the future have the recipient download it.
Moving a 256bit key anonymously can be done much more safely through the
control channel (the same way you tell the user where to download), and could
even be done in a broadcast way.

Or, USPS. There, you get first class mail protection on the contents, an easy
to understand security model, and limited user education. I'd use USPS in
preference to the SecureDrop system, and I'd sure use it in preference to
this.

------
akerl_
"Micah Lee, the staff technologist and resident crypto expert at Greenwald’s
investigative news site The Intercept. ... After reading about Greenwald’s
file transfer problem in Greenwald’s new book, "

Am I missing something, or is this part just an advert for the book? I doubt
the office's staff technologist/security_guy first heard about Greenwald's
tech security problem from his book.

With regard to the technology itself, it looks like this just uses Tor for the
file store without ever solving the hard problem: negotiating with the other
party. The tough problem here isn't hosting a file; we don't need Tor for
that. I could just as easily encrypt a file and serve it up with
[https://github.com/mikegrb/App-otfile](https://github.com/mikegrb/App-
otfile). The tough part is getting a key securely to my friend around the
world, without being MITMed or having our communication recorded and
decrypted.

------
dublinben
This being HN, I think we ought to link directly to the source, not this
secondhand coverage by Wired.

[https://github.com/micahflee/onionshare](https://github.com/micahflee/onionshare)

~~~
akerl_
Good catch!

Having looked at the code, I'm kind of alarmed by a few things. It appears to
need to run as root to manipulate iptables, and doesn't appear to drop
privileges. It also doesn't use file encryption, it relies on basic auth, and
it's serving over HTTP, so the creds and then the file go across the wire
unencrypted.

Edit: Also, bundling a bunch of related libraries in doesn't seem like a good
idea. A user either has to audit all of them for changes from the upstream
source or trust that this repo faithfully tracks updates without making
modifications.

~~~
schoen
In the specific case of Tor hidden services, using HTTP has been considered
quasi-OK because the Tor hidden service protocol encrypts (using Tor's own
transport encryption) through to the hidden service endpoint. That is, the
HTTP is actually sent via the loopback interface from the Tor client on the
hidden server to the actual application process running on the same host.
Thus, virtually all hidden websites have used the http URL scheme with the
.onion address.

I think it would be more sensible as a matter of defense in depth to not rely
on Tor's transport encryption for this purpose. I guess it's a fairly steep
challenge for UI, though, because you currently can't get a CA to issue a
certificate for a .onion name (although there is a remote possibility that
this could change if the P2P TLD RFC is adopted and then the CA/Browser Forum
agrees to recognize the P2P TLDs as legitimate subject DNS names in certs).

------
zaroth
I find it hard to take this seriously... Talking about the Tor Hidden Service;

    
    
      They provide the recipient with the URL and password for
      that site, preferably via a message encrypted with a tool
      like PGP or Off-The-Record encrypted instant messaging.
    

The hidden service URL (basically, the public key) is not secret. Sharing the
URL with PGP would just serve to link your identity to the service, if "they"
were ever able to decrypt that, which defeats the entire point of using Tor.

Put the cipher text on a Pirate Bay torrent for all it matters, the problem
reduces down to sharing the key.

Stock Tor is only 1024-bit RSA as I recall, so if you're relying on that alone
to encrypt the documents over the network you've already left the door open
for well funded attackers.

------
eliteraspberrie
_" As soon as the person has downloaded the file, you can just cancel the web
server and the file is no longer accessible to anyone," Lee says._

So your recipient would be the only person to download a file of some specific
size at some specific time, from a service that only ever served it once.
Traffic analysis is how the Tor network is attacked in practice.
Unfortunately, Onionshare is more vulnerable to traffic analysis than even the
old GnuPG and Dropbox method.

------
EGreg
Why not just use freenet?

------
rbcgerard
how is this better than, dropbox+truecrypt+tor?

~~~
higherpurpose
Much fewer steps/harder to screw up the process and expose yourself. The ideal
would be a "one-click" fully anonymous sharing of sensitive information.

~~~
akerl_
Since one of the steps is "Encrypt the URL/key with GPG and somehow get those
to the other person", I'd say it's just as many steps.

------
trvz
When the NSA is already inside the operating system and/or hardware, this
doesn't help.

