Tor at the Heart: OnionShare
During the month of December, we're highlighting other organizations and projects that rely on Tor, build on Tor, or are accomplishing their missions better because Tor exists. Check out our blog each day to learn about our fellow travelers. And please support the Tor Project! We're at the heart of Internet freedom.
By Micah Lee
In August 2013, David Miranda was detained for nine hours and searched at Heathrow Airport in London while he was trying to board a plane back home to Rio de Janeiro. Working on a journalism assignment for the Guardian, he was carrying an encrypted USB stick that contained classified government documents. When I first learned about this story, I knew there must be safer ways to move sensitive documents across the world than physically carrying them, one that didn’t involve putting individual people at risk from border agents and draconian “terrorism” laws that are used to stifle award-winning journalism.
Here’s how I would have done it: In Berlin (where the secret files originated), I would set up a local web server on my computer, that isn’t accessible from the internet. The only thing on the website would be a download link to an encrypted file that contained the secret documents. Then I would setup a Tor onion service -- one of the coolest and most under-appreciated technologies on the internet, in my opinion -- to make this simple website accessible from a special “.onion” domain name. I would send my colleague in Rio (in this case, Glenn Greenwald) the URL to the onion service. He would open it in Tor Browser and download the encrypted file. As soon as he finished the download, I would stop the local web server and remove the onion service, so it would no longer be on the internet at all.
Of course, the problem is that while this may be simple for seasoned nerds like myself, it’s not for many journalists, activists, or lawyers who run into similar problems on a regular basis. Inspired by this idea, I developed a simple and user-friendly open source tool called OnionShare that automates this process. You open OnionShare, drag some files into it, and click the “Start Sharing” button. After a moment, OnionShare gives you URL that looks something like http://4a7kqhcc7ko6a5rd.onion/logan-chopin. You send this URL to someone you’d like to share files with, and they load it using Tor Browser and download the files directly from the web server running on your computer. The moment the download is complete, OnionShare shuts down the web service, the URL no longer works, and the files you shared disappear from the internet. (Since OnionShare runs a server directly on your computer, this also means that your computer needs to be online for the URL to work -- if you suspend your laptop, for example, the URL won’t work until you get back online.)
Onionshare server side
Onionshare client side
I’m the developer of OnionShare, but I have no idea how many users it has. I consider this a feature. It’s completely decentralized, anonymous, and private. I don’t run a central service -- instead, every user runs their own short-lived service, often only for a few minutes, and that service disappears as soon as they finish sharing their files.
However, I do know that people use it. I use it on a regular basis myself while working on sensitive journalism projects with my colleagues at The Intercept. Sources use it to send me and other journalists documents. I’ve heard from digital security trainers that OnionShare is used by the Movement for Black Lives in the United States, and by activists in Latin America. A European human rights lawyer told me that their client in Africa used it to send them sensitive files.
What OnionShare protects against:
- Third parties don't have access to files being shared. The files are hosted directly on the sender's computer and don't get uploaded to any server. Instead, the sender's computer becomes the server. Traditional ways of sending files, like in an email or using a cloud hosting service like Dropbox or Google Drive, require trusting the service with access to the files being shared.
- Network eavesdroppers can't spy on files in transit. Because connections between Tor onion services and Tor Browser are end-to-end encrypted, no network attackers can eavesdrop on the shared files while the recipient is downloading them. If the eavesdropper is positioned on the sender's end, the recipient's end, or is a malicious Tor node, they will only see Tor encrypted traffic.
- Anonymity of sender and recipient are protected by Tor. OnionShare and Tor Browser protect the anonymity of the users. As long as the sender anonymously communicates the OnionShare URL with the recipient, the recipient and eavesdroppers can't learn the identity of the sender.
- If an attacker enumerates the onion service, the shared files remain safe. There have been attacks against the Tor network that can enumerate onion services. If someone discovers the .onion address of an OnionShare onion service, they still cannot download the shared files without knowing the full URL, and OnionShare has rate-limited to protect against attempts to guess the URL.
What OnionShare doesn't protect against:
- Communicating the OnionShare URL might not be secure. The sender is responsible for securely communicating the OnionShare URL with the recipient. If they send it insecurely (such as through an email message, and their email is being monitored by an attacker), the eavesdropper will learn that they're sending files with OnionShare. If the attacker loads the URL in Tor Browser before the legitimate recipient gets to it, they can download the files being shared. If this risk fits the sender's threat model, they must find a more secure way to communicate the URL, such as in an encrypted email, chat, or voice call. This isn't necessary in cases where the files being shared aren't secret.
- Communicating the OnionShare URL might not be anonymous. While OnionShare and Tor Browser allow for anonymously sending files, if the sender wishes to remain anonymous they must take extra steps to ensure this while communicating the OnionShare URL. For example, they might need to use Tor to create a new anonymous email or chat account, and only access it over Tor, to use for sharing the URL. This isn't necessary in cases where there's no need to protect anonymity, such as coworkers who know each other sharing work documents.
To get around the URL exchange (key exchange) issue you could either:
a) Pre-generate a fully random service public key and share it face-to-face before departing
b) Use one of the following to generate a predetermined string for the URL that the other party already gave you
c) If only the keys were ECC Curve 25519, you could generate them deterministically from a shared secret and a windowed timestamp.
Or just send them to the recipient using encrypted means, such as PGP, Signal, ...
The advantage of the Onionshare is that is just disappears after the usage. Nothing to trace - it is gone.
I agree that's a huge feature.
I think the original person was asking about how to get the url to your recipient though.
And for that, yes, Ricochet or the like is not a bad answer -- "however you do secure metadata-resistant messaging now."
(It seems to me that Signal and email are less good, because you leave clear metadata right before doing the thing that doesn't leave clear metadata, so you undermine your security properties.)