3 ms·

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.c

• akerl_ 12y ago
  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 12y ago
    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).