OnionShare 2 adds anonymous dropboxes(micahflee.com)
micahflee.com
OnionShare 2 adds anonymous dropboxes
https://micahflee.com/2019/02/onionshare-2/
59 comments
This is no more "security through obscurity" than say Amazon S3 signed URLs or SSH keys. They are long enough that your odds of guessing it correctly are way small. Is it possible? Sure, but so would be guessing somebody's SSH private key.
This is why I suspect they emphasized sending the URL through a secure medium (since you are basically sharing a password):
> So long as you share the unguessable web address in a secure way (like pasting it in an encrypted messaging app), no one but you and the person you're sharing with can access your files.
And also why they feel comfortable describing the web address as "unguessable"
> I'd like to see some simple one-time-use password option.
That sounds like a nice feature, although I wonder how practical it would be. I often have to refresh web pages in Tor due to timeouts and stuff. If you burned your one time password and the connection timed out, you're SOL without the person running the server issuing you a new one. A good idea tho for people willing to make that usability tradeoff.
This is why I suspect they emphasized sending the URL through a secure medium (since you are basically sharing a password):
> So long as you share the unguessable web address in a secure way (like pasting it in an encrypted messaging app), no one but you and the person you're sharing with can access your files.
And also why they feel comfortable describing the web address as "unguessable"
> I'd like to see some simple one-time-use password option.
That sounds like a nice feature, although I wonder how practical it would be. I often have to refresh web pages in Tor due to timeouts and stuff. If you burned your one time password and the connection timed out, you're SOL without the person running the server issuing you a new one. A good idea tho for people willing to make that usability tradeoff.
For what it's worth, there is some degree of password protection: the OnionShare links include a slug that must be included in order for files to be shared. Quoting the article,
> By default, OnionShare addresses look http://[tor-address].onion/[slug], where the slug is two random words out of a list of words 7,776 words (technically, this is a 2-word diceware passphrase).
> The idea is that if an attacker could figure out the tor-address part of the address, they still can't download the files you're sharing, or upload files to your computer, without first knowing the slug. The slug is, essentially, a password.
> By default, OnionShare addresses look http://[tor-address].onion/[slug], where the slug is two random words out of a list of words 7,776 words (technically, this is a 2-word diceware passphrase).
> The idea is that if an attacker could figure out the tor-address part of the address, they still can't download the files you're sharing, or upload files to your computer, without first knowing the slug. The slug is, essentially, a password.
From a security perspective, if I give a person a know https url and a password, it is indistinguishable from a know https url with the password appended in the path. There is even a standard where you can write https://username:[email protected]/
Any distinguishable security property will have to come from elsewhere, such as the web server detecting a brute force scan and blocking the request. Tor can't do this so it has to rely on the address length alone, which now can be 56 characters of A-Z and numbers 2-7. I do not know how plausible it would be to scan the whole key space, but I suspect the tor project considered this when they increase the key size with version 3. In comparison scanning the whole IPv4 network takes around 45m for the zmap project.
Let's Encrypt developers have stated interest in .onion, see: https://community.letsencrypt.org/t/if-when-will-le-support-...
The additional considerations in regard to tor is that all traffic is already end-to-end encrypted with identity being served through the address. In regard to https there isn't much left, beyond enabling standards like http2 which explicitly require https and browser security features which are only enabled when visiting a https website.
Any distinguishable security property will have to come from elsewhere, such as the web server detecting a brute force scan and blocking the request. Tor can't do this so it has to rely on the address length alone, which now can be 56 characters of A-Z and numbers 2-7. I do not know how plausible it would be to scan the whole key space, but I suspect the tor project considered this when they increase the key size with version 3. In comparison scanning the whole IPv4 network takes around 45m for the zmap project.
Let's Encrypt developers have stated interest in .onion, see: https://community.letsencrypt.org/t/if-when-will-le-support-...
The additional considerations in regard to tor is that all traffic is already end-to-end encrypted with identity being served through the address. In regard to https there isn't much left, beyond enabling standards like http2 which explicitly require https and browser security features which are only enabled when visiting a https website.
> I'd like to see some simple one-time-use password option.
I also agree with this. But I think the "delete once files are downloaded" kinda fulfills this. It does become insecure if someone else accesses it first, but then you know that someone else downloaded the data, right?
For the multiple sharing I think a password would be a really nice feature. You could have that done on the user side, but a good password implementation would be awesome.
I also agree with this. But I think the "delete once files are downloaded" kinda fulfills this. It does become insecure if someone else accesses it first, but then you know that someone else downloaded the data, right?
For the multiple sharing I think a password would be a really nice feature. You could have that done on the user side, but a good password implementation would be awesome.
I wonder if scrambled distributed chunks over torrent would be useful.
Btw who works on tor replacement or improvement ?
Btw who works on tor replacement or improvement ?
Related work; on the deniable side: shadowsocks, a proxy designed to look like https traffic, wireguard may fulfill the same kind of goal (using generic session protocols like the noise framework might help deniability); on the generic p2p internet/web: gnunet (large project, quite experimental, has naming, routing/transport, some application protocols).
many thanks
Just to clarify, HTTPS would not be of any use if the sole verification you make is technical (eg like letsencrypt which verifies that you indeed control the endpoint, vs say <commercial CA> that may verify IRL that you are the social entity you say you are). tldr: if you trust the onion address to be correct, the connection is already end-to-end encrypted to the only person that generated and thus controls the endpoint.
I didn't look into onion addresses in some time so correct me if i'm wrong, but basically the address is a certificate: a locator and a key (both being the same thing but still). Links are authenticating by default, as if you bundled a letsencrypt certificate in the url. Some keywords to explore further: cjdns (same thing on osi level 3), capability-based security (tying an name [in the sense of URN] and a key), content-based addressing (can be seen as a variant when content is static, in tor the name points to a channel and not a blob so the content is the key).
I didn't look into onion addresses in some time so correct me if i'm wrong, but basically the address is a certificate: a locator and a key (both being the same thing but still). Links are authenticating by default, as if you bundled a letsencrypt certificate in the url. Some keywords to explore further: cjdns (same thing on osi level 3), capability-based security (tying an name [in the sense of URN] and a key), content-based addressing (can be seen as a variant when content is static, in tor the name points to a channel and not a blob so the content is the key).
Onions broadcast themselves to the directory to they can be accessed
This is awesome, however, if you're looking for plausible deniability this can cause some concern.
Tor traffic is pretty visible and detectable. If you're firewalled somewhere, it's pretty obvious to anyone in the middle that you're using Tor. Tools like these clearly don't work against nation states like China, or even some corporate environments.
Transferring secrets in a plausibly deniable format is still a hard problem.
Tor traffic is pretty visible and detectable. If you're firewalled somewhere, it's pretty obvious to anyone in the middle that you're using Tor. Tools like these clearly don't work against nation states like China, or even some corporate environments.
Transferring secrets in a plausibly deniable format is still a hard problem.
You are probably talking about detecting Tor relay nodes IP addresses that the sender connects to or patterns in the traffic.
So you could use a VPN, or a chain of VPNs to hide the IP.
And to escape traffic analysis you could switch the entry VPN automatically (that would require quite a few VPNs for large files or many receivers).
Still, connecting to unknown IPs from a corporate network can be detected.
Then you could use some public service that stores data like Github (repos / gists / ...) and somehow communicate between your computer and a relay server through Github.
Still not foolproof, there could be timing attacks to detect when data is transmitted when the receiver requests the file, so introducing delays along the nodes would help.
So you could use a VPN, or a chain of VPNs to hide the IP.
And to escape traffic analysis you could switch the entry VPN automatically (that would require quite a few VPNs for large files or many receivers).
Still, connecting to unknown IPs from a corporate network can be detected.
Then you could use some public service that stores data like Github (repos / gists / ...) and somehow communicate between your computer and a relay server through Github.
Still not foolproof, there could be timing attacks to detect when data is transmitted when the receiver requests the file, so introducing delays along the nodes would help.
Systemic solution to this problem: NNTP (Usenet). I can't recall the specific newsgroup, but there are Usenet "numbers stations" groups for the upload of anonymous encrypted binaries. They get store-and-forward-ed like anything else, at arbitrary times.
Alice dumps an encrypted document into the NNTP network on one side of the world; Bob later downloads the entire newsgroup's contents (not just the stuff he wants—because there's no metadata to even determine that!) from his local NNTP server, and then attempts to decrypt everything he downloaded until he hits on something that works.
Alice dumps an encrypted document into the NNTP network on one side of the world; Bob later downloads the entire newsgroup's contents (not just the stuff he wants—because there's no metadata to even determine that!) from his local NNTP server, and then attempts to decrypt everything he downloaded until he hits on something that works.
But wouldn't that have the same problem that GP mentioned, that this traffic would be easily identifiable as NNTP? If you were the only person using NNTP, then whammo...
One part of this scheme that I forgot about, which the link in the sibling reply mentions, is MixMaster (http://mixmaster.sourceforge.net/faq.shtml#1.2), a self-hostable service for “mixing” SMTP traffic (including SMTP>NNTP gateway traffic) around. Many people host these, even today. It’s a bit like Mailinator with all its alias domains, but for the other end of the connection, and distributed.
So, to get all the security features at the same time:
1. Using Tor to hide your IP,
2. Connect to a MixMaster node (using TLS), and
3. Send an encrypted NNTP message through it,
4. To an SMTP>NNTP gateway,
5. With the embedded NNTP message’s Recipient being alt.messages.anonymous.
Kinda complicated, but you could wrap all that up into a nice GUI program if you wanted.
Oh wait, they already did: http://aamdirect.sourceforge.net
——
MixMaster doesn’t do the Tor part for you, though. My suggestion would be to run AAM Direct in a https://tails.boum.org session, which will automatically force the connection through Tor without any configuration needed.
An additional boost to security would be for there to be .onion MixMaster nodes, so that the traffic doesn’t have to traverse the public internet (and thus probably force you to rely on the only-kind-of-secure SMTP STARTTLS extension for security between the Tor exit node and the MixMaster node.)
So, to get all the security features at the same time:
1. Using Tor to hide your IP,
2. Connect to a MixMaster node (using TLS), and
3. Send an encrypted NNTP message through it,
4. To an SMTP>NNTP gateway,
5. With the embedded NNTP message’s Recipient being alt.messages.anonymous.
Kinda complicated, but you could wrap all that up into a nice GUI program if you wanted.
Oh wait, they already did: http://aamdirect.sourceforge.net
——
MixMaster doesn’t do the Tor part for you, though. My suggestion would be to run AAM Direct in a https://tails.boum.org session, which will automatically force the connection through Tor without any configuration needed.
An additional boost to security would be for there to be .onion MixMaster nodes, so that the traffic doesn’t have to traverse the public internet (and thus probably force you to rely on the only-kind-of-secure SMTP STARTTLS extension for security between the Tor exit node and the MixMaster node.)
You can use NNTP over SSL, but I'm not sure the certificates get safely checked or if its snake oil...
This sounds fascinating. Do you have a link?
Is there any kind of standard that 'defines' what a plausibly deniable format is?
Simply something that looks like a widespread/legitimate encrypted stream format. Nowadays this mostly means that your traffic seems to be https (eg tls/tcp). If you want UDP transport maybe an option would be to masquerade some media protocol like SRTP.
Isn't that exactly the problem Tor's pluggable transports are designed to solve?
For those looking to do this programmatically, it is so easy these days. This project uses the Python library Stem [0] and I wrote one for Go called Bine [1]. Firing up a website on an onion service from your home computer is really easy, and busts NAT by its nature.
0 - https://stem.torproject.org/ 1 - https://github.com/cretz/bine
0 - https://stem.torproject.org/ 1 - https://github.com/cretz/bine
I wonder if you could use this to make an OnionSync. Like Syncthing but perhaps simpler to use because of global addressing and no need to configure between nodes. (Though I've only briefly looked at Syncthing.
If you control both sides of the connection, ZeroTier is probably a more efficient "NAT-busting E2E-encrypted overlay network" solution than anything Tor-based.
You don't need to configure Syncthing either, you just pair it and then it automatically always just works.
Similar sharing, but not onion routed.
https://github.com/datproject/dat
https://github.com/datproject/dat
I think it's actually more similar to magic-wormhole, https://github.com/warner/magic-wormhole
Really like the ephemeral links, don’t love the fact that the receiving party needs to use a tor browser....
Firefox is apparently working towards integrating Tor into a private browsing mode type of thing, so perhaps someday soon that won't be necessary [0].
[0] https://news.ycombinator.com/item?id=17205441
[0] https://news.ycombinator.com/item?id=17205441
Brave browser now has a Private Browsing mode with Tor.
> .. is to use an encrypted messaging app like Signal Desktop, Wire, Keybase, or iMessage.
Solid selection by authors, not familiar with Keybase though
Solid selection by authors, not familiar with Keybase though
Keybase is basically a communication platform that's secure, but allows the users to verify that they are who they say they are. It's basically like "I am foo, and I identify myself like this, and you are bar, and you identify yourself like that, we now know that we are who we say we are, and now we're having an e2e encrypted conversation.
It's supposedly a way to put a stop to imitation, but unless adoption gets huge I'm not sure it'll work that way.
It generates a string, you store it on, for example, your twitter, facebook, github, HN account, almost anything with an editable profile. That way when 2 users are talking, one can be assured that the other is who they claim to be (either that or they have access to all of said person's accounts). It's kind of cool but it's impractical in a way that usage is pretty low (at least among people I know. Maybe it's got a big underground following I don't know about).
I have a keybase account and literally no one else I know does, so I've never used it.
It's supposedly a way to put a stop to imitation, but unless adoption gets huge I'm not sure it'll work that way.
It generates a string, you store it on, for example, your twitter, facebook, github, HN account, almost anything with an editable profile. That way when 2 users are talking, one can be assured that the other is who they claim to be (either that or they have access to all of said person's accounts). It's kind of cool but it's impractical in a way that usage is pretty low (at least among people I know. Maybe it's got a big underground following I don't know about).
I have a keybase account and literally no one else I know does, so I've never used it.
I love Keybase (it has some awesome features, like chat (similar to slack), encrypted file storage, encrypted git repos etc. But you're right you have to have other people using it for it to have any value. I've gotten work colleagues to adopt it so now it's also a great way to stay in touch after somebody leaves the company.
If you want to look me up on Keybase I'm freedomben, and I'll be your friend :-)
If you want to look me up on Keybase I'm freedomben, and I'll be your friend :-)
Honest question: do tools like this even matter? We're all a few INNER JOINs away from having our entire lives known by data brokers. This seems to indicate that unless one changes their name and lives with the mole people, privacy is an illusion.
To name a few professional that need to talk work with each others: journalists, lawyers, medical personal, security, and government. If just a small amount of the sensitive information that get transported through data brokers like facebook and google get moved to more secure end-to-end then I see a major win for projects like this. Take for example a psychologist seeking a second opinion on a recorded video of a patient, which as I understand is a rather standard practice. If I was the patient then I wish they used tools like this rather than a password protected google drive, which for practical reasons I assume many non-technical psychologist use.
Most people will not see the logical conclusion of this whole ordeal and will think you are merely being pessimistic.
Pandora's box cannot be shut. TOR and other projects will not be able to delete the information already gathered, backed up and parsed.
People are happy to tell everyone else what they ate, where they went, with whom and what they are thinking about at all times in exchange for nothing.
Society has made it clear that this erosion of privacy is a non issue.
-------------------
ERROR - Value 'privacy' not found.
Sorry, the value you have chosen to uphold is no longer supported in the latest version of civilisation.
Please select another from the whitelist below.
Pandora's box cannot be shut. TOR and other projects will not be able to delete the information already gathered, backed up and parsed.
People are happy to tell everyone else what they ate, where they went, with whom and what they are thinking about at all times in exchange for nothing.
Society has made it clear that this erosion of privacy is a non issue.
-------------------
ERROR - Value 'privacy' not found.
Sorry, the value you have chosen to uphold is no longer supported in the latest version of civilisation.
Please select another from the whitelist below.
I wonder, does this support threaded transfer? It really bugs me that so many tools don't, and therefore just leave users waiting around with unused internet bandwidth.
Of course, I suppose the design of TCP is part of this. It seems that there ought to be some more control of how aggressive it is about dropping connection rate. I keep hearing about multiplexed connections in newer protocols (QUIC etc.); would that translate into saturation of network connections?
Of course, I suppose the design of TCP is part of this. It seems that there ought to be some more control of how aggressive it is about dropping connection rate. I keep hearing about multiplexed connections in newer protocols (QUIC etc.); would that translate into saturation of network connections?
TCP often fails to saturate network links because it treats packet loss as congestion. TCP-BBR tries to model the network more accurately, treating latency as congestion: https://cloud.google.com/blog/products/gcp/tcp-bbr-congestio...
Tor adds additional complexities, since intermediate nodes are even more likely to be congested than the average backbone router. I don't know if BBR improves things there.
Tor adds additional complexities, since intermediate nodes are even more likely to be congested than the average backbone router. I don't know if BBR improves things there.
Hmm, interesting thought. This explains why google drive, youtube, etc. can download so quickly with a single connection (especially compared with other services). Thanks for the link.
See also Firefox Send - https://send.firefox.com/
Files are encrypted and then uploaded to Mozilla servers. Links automatically expire after some time.
Files are encrypted and then uploaded to Mozilla servers. Links automatically expire after some time.
This is not metadata analysis resistant, so Mozilla could still technically see who is sending files to who (unless you use Firefox Send in Tor Browser - not sure how well that works).
That's not to say this service isn't useful, but it's not a drop-in alternative to OnionShare.
That's not to say this service isn't useful, but it's not a drop-in alternative to OnionShare.
Someone should release a version of Tor where users set the private key of their hidden service to something human readable (with the necessary mapping and padding).
Then someone wanting to access the hidden addy types that same private key in the url bar of a correspondingly twisted Tor Browser which would generate the hidden service pubkey and request the service at that addy.
Who wants to surf fwodjslkf...sdfjs.onion when you could be surfing amazon.onion?
It's also more democratic because if you don't like what you find there you can just publish your own amazon.onion.
Then someone wanting to access the hidden addy types that same private key in the url bar of a correspondingly twisted Tor Browser which would generate the hidden service pubkey and request the service at that addy.
Who wants to surf fwodjslkf...sdfjs.onion when you could be surfing amazon.onion?
It's also more democratic because if you don't like what you find there you can just publish your own amazon.onion.
You can't do that because that's not the way encryption works.
The reason onion addresses are random looking is because they are a function of the hidden service's public key.
If you could generate a "private key" from the public key, anyone could use your "domain name". The reason tor doesn't require centralised domain name services is because we can trust that whoever owns the private key to the public key which we identify with the onion address, owns the onion address.
The reason onion addresses are random looking is because they are a function of the hidden service's public key.
If you could generate a "private key" from the public key, anyone could use your "domain name". The reason tor doesn't require centralised domain name services is because we can trust that whoever owns the private key to the public key which we identify with the onion address, owns the onion address.
> If you could generate a "private key" from the public key,
That's not what I wrote at all. I'm just talking about downgrading the onion addy generation to become a simple password authentication scheme. It's bad but no worse than logging into webmail without any 2FA.
If you really don't understand what I'm talking about I can put together a PoC. But it's extremely straightforward so I'd rather not if you can just re-read what I wrote and grok the idea.
That's not what I wrote at all. I'm just talking about downgrading the onion addy generation to become a simple password authentication scheme. It's bad but no worse than logging into webmail without any 2FA.
If you really don't understand what I'm talking about I can put together a PoC. But it's extremely straightforward so I'd rather not if you can just re-read what I wrote and grok the idea.
The closest you could get to OP's idea is to have a human-readable, non-configurable (but minable) mnemonic that maps to a public key.
This has been tried quite a bit ranging from proquint to random 32-bit phrases [0]. I just don't think we as humans are going to be able to make something both memorable and with enough size to hold, say, ed25519 keys (i.e. Tor v3 keys). KDFs leave a lot to be desired too, we're going to have to find a better way. Until then, obtuse names and lack of easy discovery will plague decentralized setups.
0 - https://blog.asana.com/2011/09/6-sad-squid-snuggle-softly/
0 - https://blog.asana.com/2011/09/6-sad-squid-snuggle-softly/
Or just "mining" vanity addresses like facebookcorewwwi.onion
Uh, what?
What you describe doesn't sound remotely feasible...
What you describe doesn't sound remotely feasible...
Here's a bad idea
1. Set a hidden service private key to all zeros.
2. Derive the public key from that private key (plus whatever else you must do) to generate the corresponding onion address for that all-zeros private key.
3. Type that onion address into a Tor browser and see what you get back.
If what I just described is not even "remotely feasible," then one ought to be willing to type that addy into Tor browser running on their raw hardware and rest assured there is no possible way someone is running a (probably nefarious) service running at that address.
Are you willing to do that?
If not, what I'm talking about is just adding some leading, non-random, nonzero bits to that "all-zeros" private key.
It's not a secure design, but if all people want is to send files that are too big for email it's no worse than using password authentication to log in to, say, msn.com.
1. Set a hidden service private key to all zeros.
2. Derive the public key from that private key (plus whatever else you must do) to generate the corresponding onion address for that all-zeros private key.
3. Type that onion address into a Tor browser and see what you get back.
If what I just described is not even "remotely feasible," then one ought to be willing to type that addy into Tor browser running on their raw hardware and rest assured there is no possible way someone is running a (probably nefarious) service running at that address.
Are you willing to do that?
If not, what I'm talking about is just adding some leading, non-random, nonzero bits to that "all-zeros" private key.
It's not a secure design, but if all people want is to send files that are too big for email it's no worse than using password authentication to log in to, say, msn.com.
Url changed from https://blog.torproject.org/new-release-onionshare-2, which points to this.
As an aside, please guys, consider using Tor for more of your day to day browsing. The anonymity of the Tor network crucially depends on more users and more traffic to defeat global adversaries or timing attacks (or at least make it more difficult).
Is there any way to use it without it being painfully slow?
In my experience, it is slow only on very media heavy sites like Facebook, Youtube etc. That's not going to improve unless there are many more exit nodes and relays. But for most browsing its not painfully slow, although the slight delay is noticeable when compared to a non-Tor browser. However I guess the best way to fight public perception that Tor is a den of illegal activities, as well as foil timing attacks is for more of us to use it for regular browsing.
For Facebook, you can use its onion service to get improved speeds (the traffic doesn't leave the Tor network, which itself is quite fast, it is only the exits to the Internet which are slow): https://facebookcorewwwi.onion/
It's not painfully slow these days, it's quite fast actually
I know Onion addresses are huge and the chance of someone scanning to upload is tiny, but I remember saying the same thing about IPv4. "There's 256^4 addresses, of course I can run an unsecured FTP. What could go wrong?"
I'd like to see some simple one-time-use password option. It doesn't even have to be enabled by default, just having it there would be a big step. HTTPS would be great, but I understand the difficulty of that hurdle.
(If Let's Encrypt is out there - .onion isn't a dirty word!)