this blog post is the second issue of the Cooking with Onions series which aims to highlight interesting aspects of the onion space. Check-out our first issue as well!
Onion addresses are weird...
This post is about onion addresses being weird and the approaches that can be taken to improve onion service usability.
In particular, if you've cruised around the onionspace, you must have noticed that onion services typically have random-looking addresses that look like these:
To better understand why onion addresses are so strange, it helps to remember that onion services don't use the insecure Domain Name System (DNS), which means there is no organization like ICANN to oversee a single root registry of onion addresses or to handle ownership dispute resolution of onion addresses. Instead, onion services get strong authentication from using self-authenticating addresses: the address itself is a cryptographic proof of the identity of the onion service. When a client visits an onion service, Tor verifies its identity by using the address as ground truth.
In other words, onion services have such absurd names because of all the cryptography that's used to protect them. Cryptographic material are basically huge numbers that look meaningless to most humans, and that's the reason onion addresses tend to look random as well.
To motivate this subject further, Tor developers have medium-term future plans for upgrading the cryptography of onion services, which has the side-effect of increasing onion address length to 54 characters! This means that in the future onion addresses will look like this:
Over the years the Tor community has come up with various ways of handling these large and non-human-memorable onion addresses. Some people memorize them entirely or scribe them into secret notebooks, others use tattoos, third-party centralized directories or just google them everytime. We've heard of people using decks of cards to remember their favorite onion sites, and others who memorize them using the position of stars and the moon.
We believe that the UX problem of onion addresses is not actually solved with the above ad-hoc solutions and remains a critical usability barrier that prevents onion services from being used by a wider audience.
The onion world never had a system like DNS. Even though we are well aware that DNS is far from the perfect solution, it's clear that human memorable domain names play a fundamental role in the user experience of the Internet.
In this blog post we present you a few techniques that we have devised to improve the usability of onion addresses. All of these ideas are experimental and come with various fun open questions, so we are still in exploration mode. We appreciate any help in prototyping, analyzing and finding flaws in these ideas.
Idea 1) A modular name system API for Tor onion services
During the past years, many research groups have experimented and designed various secure name systems (e.g. GNS, Namecoin, Blockstack). Each of these systems has its own strengths and weaknesses, as well as different user models and total user experience. We are not sure which one works best for the onion space, so ideally we'd like to try them all and let the community and the sands of time decide for us. We believe that by integrating these experimental systems into Tor, we can greatly strengthen and improve the whole scientific field by exposing name systems to the real world and an active and demanding userbase.
For this reason and based on our experience with modular anti-censorship techniques, we designed a generic & modular scheme through which any name system can be integrated to Tor: Proposal 279 defines A Name System API for Tor Onion Services which can be used to integrate any complex name system (e.g. Namecoin) or even simple silly naming schemes (e.g. a local /etc/tor-hosts file).
It's worth pointing out that proposal 279 is in draft status and we still need to incorporate feedback received in the mailing list. Furthermore, people have pointed out simple ways through which we can fast-track and prototype the proposal faster. Help in implementing this proposal is greatly appreciated (find us in IRC!).
Idea 2) Using browser extensions to improve usability
Other approaches for improving the usability of onion addresses use the Tor Browser as a framework: think of browser extensions that map human memorable names to onion addresses.
There are many variants here so let's walk through them:
Idea 2.1) Browser Extension + New pseudo-tld + Local onion registry
A browser extension like HTTPS-everywhere, uses an onion registry to map human-memorable addresses from a new pseudo-tld (e.g. ".tor") to onion addresses. For example, it maps "watchtower.tor" to "fixurqfuekpsiqaf.onion" and "globaleconomy.tor" to "froqh6bdgoda6yiz.onion". Such an onion registry could be local (like HTTPS-everywhere) or remote (e.g. a trusted append-only database).
Even an extension with a local onion registry would be a very effective improvement to the current situation since it would be pretty usable and its security model is easy to understand: an audited local database seems to work well for HTTPS-everywhere. However, there are social issues here: how would the onion registry be operated and how should name registrations be handled? I can see people fighting for who will get bitcoin.tor first. That said, this idea can be beneficial even with a small onion database (e.g. 50 popular domains).
Here is a graphical depiction of a browser extension with a local onion registry resolving the domain sailing.tor for a user:
Idea 2.2) Browser extension + New pseudo-tld + Remote onion registries
A more dynamic alternative here involves multiple trusted remote onion registries that the user can add to their torrc. Imagine a web-of-trust based system where you add your friend's Alice onion registry and then you can visit facebook using facebook.alice.onion.
A similar more decentralized alternative could be a browser addon that uses multiple remote onion registries/notaries to resolve a name, employing a majority or supermajority rule to decide the resolution results. Such a system could involve notary nodes similar to SSL schemes like Convergence.
Idea 2.3) Browser extension redirects existing DNS names
An easier but less effective approach would be for the browser extension to only map DNS domain names to onion names. So for example, it would map "duckduckgo.com" to "3g2upl4pq6kufc4m.onion". That makes the job of the name registrar easier, but it also heavily restricts users only to services with a registered DNS domain name. Some attempts have already been made in this area but unfortunately they never really took off.
Idea 2.4) Automatic Redirection using HTTP
The Alt-Svc HTTP header defines a way for a website to say "I'm facebook.com but you should talk to me using fbcdn.com." If we replace that fbcdn.com address with facebookcorewwi.onion - then when you typed in Facebook, the browser would, under the covers, use the .onion address. And this can be done without any browser extension whatsoever.
One problem is that the browser has to remember this mapping, and in Tor Browser that mapping could be used to track or correlate you. Preloading the mapping would solve this, but how to preload the mapping probably brings us back into the realm of a browser extension.
Idea 2.5) Smart browser bookmarks for onion addresses
Talking about random addresses, it's funny how people seem to be pretty happy handling phone numbers (big meaningless random numbers) using a phone book and contacts on their devices.
On the same note, an easier but less usable approach would be to enhance Tor Browser with some sort of smart bookmark/petname system which allows users to register custom names for onion sites, and allows them to trust them or share them with friends. Unfortunately, it' unclear whether the user experience of this feature would make it useful to anyone but power users.
Of course it's important to realize that any approach that relies on a browser extension will only work for the web, and you wouldn't be able to use it for arbitrary TCP services (e.g. visiting an IRC server)
Idea 3) Embed onion addresses in SSL certificates
So let's shift back to non-browser approaches!
Let's Encrypt is an innovative project which issues free SSL certificates in an automated fashion. It has greatly improved Internet security since now anyone can freely acquire an SSL certificate for their service and provide link security to their users.
Now let's imagine that Let's Encrypt embedded onion address information into the certificates it issues, for clients with both a normal service and an onion service. For example, the onion address could be embedded into a custom certificate extension or in the C/ST/L/O fields. Then Tor Browser, when visiting such an SSL-enabled website, would parse and validate the certificate and if an onion address is included, the browser would automagically redirect the user. Take a look at this paper for some more neat ideas on this area.
Idea 4) Embed onion addresses in DNS/DNSSEC records
A similar approach could use the DNS system instead of the SSL CA system. For example, site owners could add their onion address into their TXT or SRV DNS records and Tor could learn to redirect users to the onion address. Of course this approach only applies to operators that can afford a DNS domain. Oh yeah DNS also has zero security...
As you can see there are many approaches that we should explore to improve usability in this area. Each of them comes with its own tradeoffs and applies to different users, so it's important that we allow users to experiment with various systems and let each community decide which approach works best for them.
It's also worth pointing out that some of these approaches are not that hard to implement technically, but they still require lots of effort and community building to really take off and become effective. Involving and pairing with other friendly Internet privacy organizations is essential to achieve our goals.
Furthermore, we should think carefully of unintended usability and security consequences that come with using these systems. For example, people are not used to their browser automagically redirecting them from one domain to another: this can seriously freak people out. It's also not clear how Tor Browser should handle these special names to avoid SSL certificate verification issues and hostname leaks.
One thing is for sure: even though onion services are used daily by thousand of people, the random addresses confuse casual users and prevent the ecosystem from maturing and achieving widespread adoption. We hope that this blog post inspires researchers and developers to toy around with naming systems and take the initiative in building and experimenting with the various approaches. Please join the [tor-dev] mailing list and share your thoughts and projects with us!
And this brings us to the end of this post. Hope you enjoyed this issue of Cooking With Onions! We will be back soon, always with the finest produce and the greatest cooking tips! What would you like us to cook next?
[Thanks to Philipp Winter and Tom Ritter for the feedback on this blog post, as well as to everyone who has discussed and helped develop these ideas.]
Today, we've released the first stable version of the 0.2.9.x series, bringing exciting new features to Tor. The series has seen 1406 commits from 32 different contributors. Please, see the ChangeLog for more details about what has been done.
This post will outline three features (among many other things) that we are quite proud of and want to describe in more detail.
Single Onion Service
Over the past several years, we've collaborated with many large scale service providers such as Facebook and Riseup, organizations that deployed Onion Services to improve their performance.
Onion services are great because they offer both anonymity on the service and the client side. However, there are cases where the onion service does not require anonymity. The main example of this is when the service provider does not need to hide the location of its servers.
As a reminder to the reader, an onion service connection between a client and a service goes through 6 hops, while a regular connection with Tor is 3 hops. Onion services are much slower than regular Tor connections because of this.
Today, we are introducing Single Onion Services! With this new feature, a service can now specify in its configuration file that it does not need anonymity, thus cutting the 3 hops between the service and its Rendezvous Point and speeding up the connection.
For security reasons, if this option is enabled, only single onion service can be configured. They can't coexist with a regular onion service. Because this removes the anonymity aspect of the service, we took extra precautions so that it's very difficult to enable a single onion by mistake. In your torrc file, here is how you do it:
Please read about these options before you enable them in the manual page.
We've talked about this before but now it is a reality. At midnight UTC every day, directory authorities collectively generate a global random value that cannot be predicted in advance. This daily fresh random value is the foundation of our next generation onion service work coming soon to a Tor near you.
In the consensus file, they will look like this; if all goes well, at 00:00 UTC, consensus will have a new one:
Thanks to atagar, the Stem Library version 1.5.0 supports parsing the shared random values from the consensus. See here for more information!
Voluntarily, we haven't exposed those values to the control port yet and will wait for a full stable release cycle in order to make sure it's stable enough for a third party application to use them (https://trac.torproject.org/19925).
Mandatory ntor handshake
This is another important security feature introduced in the new release. Authorities, relays and clients now require ntor keys in all descriptors, for all hops, for all circuits, and for all other roles.
In other words, except for onion services (and this will be addressed with the next generation), only ntor is used--now finally dropping the TAP handshake.
This results in better security for the overall network and users.
Enjoy this new release!
This blog post is the first part of the Cooking with Onions series which aims to highlight various interesting developments on the .onion space. This particular post presents a technique for efficiently scaling busy onion services.
The need for scaling
Onion services have been around for a while. During the past few years, they have been deployed by many serious websites like major media organizations (like the Washington Post), search engines (such as DuckDuckGo) and critical Internet infrastructure (e.g. PGP keyservers). This has been a great opportunity for us, the development team, since our code has been hardened and tested by the sheer volume of clients that use it every day.
This recent widespread usage also gave us greater insights on the various scalability issues that onion service operators face when they try to take their service to the next level. More users means more load to the onion service, and there is only so much that a single machine can handle. The scalability of the onion service protocol has been a topic of interest to us for a while, and recently we've made advancements in this area by releasing a tool called OnionBalance.
So what is OnionBalance?
OnionBalance is software designed and written by Donncha O'Cearbhaill as part of Tor's Summer of Privacy 2015. It allows onion service operators to achieve the property of high availability by allowing multiple machines to handle requests for a single onion service. You can think of it as the onion service equivalent of load balancing using round-robin DNS.
OnionBalance has recently started seeing more and more usage by onion service operators! For example, the Debian project recently started providing onion services for its entire infrastructure, and the whole project is kept in line by OnionBalance.
How OnionBalance works
Consider Alice, an onion operator, who wants to load balance her overloaded onion service using OnionBalance.
She starts by setting up multiple identical instances of that onion service in multiple machines, makes a list of their onion addresses, and passes the list to OnionBalance. OnionBalance then fetches their descriptors, extracts their introduction points, and publishes a "super-descriptor" containing all their introduction points. Alice now passes to her users the onion address that corresponds to the "super-descriptor". Multiple OnionBalance instances can be run with the same configuration to provide redundancy when publishing the super descriptor.
When Bob, a client, wants to visit Alice's onion service, his Tor client will pick a random introduction point out of the super-descriptor and use it to connect to the onion service. That introduction point can correspond to any of the onion service instances, and this way the client load gets spread out.
With OnionBalance, the "super-descriptor" can be published from a different machine to the one serving the onion service content. Your onion service private key can be kept in a more isolated location, reducing the risk of key compromise.
For information on how to set up OnionBalance, please see the following article:
OnionBalance is a handy tool that allows operators to spread the load of their onion service to multiple machines. It's easy to set up and configure and more people should give it a try.
In the meanwhile, we'll keep ourselves busy coming up with other ways to scale onion services in this brave new world of onions that is coming!
Take care until the next episode :)
A few weeks ago, a small group of Tor developers got together in Montreal and worked on onion services for a full week. The event was very rewarding and we wrote this blog post to share with you how we spent our week! For the record, it was our second onion service hackfest, following the legendary Arlington Accords of July 2015.
Our main goal with this meeting was to accelerate the development of the Next Generation Onion Services project (aka proposal 224). We have been working on this project for the past several months and have made great progress. However, it's a huge project! Because of its volume and complexity, it has been extremely helpful to meet and work together in the same physical space as we hammer out open issues, review each other's code, and quickly make development decisions that would take days to coordinate through mailing lists.
During the hackfest, we did tons of work. Here is an incomplete list of the things we did:
- In our previous hidden service hackfest, we started designing a system for distributed random number generation on the Tor network. A "distributed random number generator" is a system where multiple computers collaborate and generate a single random number in a way that nobody could have predicted in advance (not even themselves). Such a system will be used by next generation onion services to inject unpredictability into the system and enhance their security.
Tor developers finished implementing the protocol several months ago, and since then we've been reviewing, auditing, and testing the code.
As far as we know, a distributed random generation system like this has never been deployed before on the Internet. It's a complex system with multiple protocol phases that involves many computers working together in perfect synergy. To give you an idea of the complexity, here are the hackfest notes of a developer suggesting a design improvement to the system:
Complicated protocols require lots of testing! So far, onion service developers have been testing this system by creating fake small virtual Tor networks on their laptops and doing basic tests to ensure that it works as intended. However, that's not enough to properly test such an advanced feature. To really test something like this, we need to make a Tor network that works exactly like the real Tor network. It should be a real distributed network over the Internet, and not a virtual thing that lives on a single laptop!
And that's exactly what we did during the Montreal hackfest! Each Tor developer set up their own Tor node and enabled the "distributed random number generation" feature. We had Tor nodes in countries all around the world, just like the real Tor network, but this was a network just for ourselves! This resulted in a "testing Tor network" with 11 nodes, all performing the random number generation protocol for a whole week.
This allowed us to test scenarios that could make the protocol burp and fail in unpredictable ways. For example, we instructed our testing Tor nodes to abort at crucial protocol moments, and come back in the worst time possible ways, just to stress test the system. We had our nodes run ancient Tor versions, perform random chaotic behaviors, disappear and never come back, etc.
This helped us detect various bugs and edge cases. We also confirmed that our system can survive network failures that can happen on the real Internet. All in all, it was a great educational experience! We plan to keep our testing network live, and potentially recruit more people to join it, to test even more features and edge cases!
For what it's worth, here is a picture of the two first historic random values that our Tor test network generated. The number "5" means that 5 Tor nodes contributed randomness in generating the final random value:
- We also worked to improve the design of next generation onion services in other ways. We improved the clarity of the specification of proposal 224 and fixed inconsistencies and errors in the text (see latest prop224 commits).
We designed various improvements to the onion service descriptor download logic of proposal 224 as well as ways to improve the handling of clients with skewed clocks. We also brainstormed ways we can improve the shared randomness protocol in the future.
We discussed ways to improve the user experience of the 55-character-long onion addresses for next generation onion services (compared to the 16-character-long onion addresses used currently). While no concrete design has been specified yet, we identified the need for a checksum and version field on them. We also discussed modifications to the Tor Browser Bundle that could improve the user experience of long onion addresses.
- We don't plan to throw away the current onion service system just yet! When proposal 224 first gets deployed, the Tor network will be able to handle both types of onion services: the current version and the next generation version.
For this reason, while writing the code for proposal 224, we've been facing the choice of whether to refactor a particular piece of code or just rewrite it completely from scratch. The Montreal hackfest allowed us to make quick decisions about these, saving tons of time we would have spent trying to decide over mailing lists and bug trackers.
- We also worked on breaking down further the implementation plan for proposal 224. We split each task into smaller subtasks and decided how to approach them. Take a look at our notes.
All in all, we got crazy amounts of work done and we all have our hands full for months to come.
Finally, if you find these sort of hackfests exciting and you would like to host or sponsor one, don't hesitate to get in touch with us! Contact us at firstname.lastname@example.org and we will forward your message to the appropriate people.
Be seeing you!
1. What are your priorities for onion services development?
Personally I think it’s very important to work on the security of hidden services; that’s a big priority.
The plan for the next generation of onion services includes enhanced security as well as improved performance. We’ve broken the development down into smaller modules and we’re already starting to build the foundation. The whole thing is a pretty insane engineering job.
2. What don't people know about onion Services?
Until earlier this year, hidden services were a labor of love that Tor developers did in their spare time. Now we have a very small group of developers, but in 2016 we want to move the engineering capacity a bit farther out. There is a lot of enthusiasm within Tor for hidden services but we need funding and more high level developers to build the next generation.
3. What are some of Tor's plans for mitigating attacks?
The CMU attack was fundamentally a "guard node" attack; guard nodes are the first hop of a Tor circuit and hence the only part of the network that can see the real IP address of a hidden service. Last July we fixed the attack vector that CMU was using (it was called the RELAY_EARLY confirmation attack) and since then we've been divising improved designs for guard node security.
For example, in the past, each onion service would have three guard nodes assigned to it. Since last September, each onion service only uses one guard node—-it exposes itself to fewer relays. This change alone makes an attack against an onion service much less likely.
Several of our developers are thinking about how to do better guard node selection. One of us is writing code on this right now.
We are modeling how onion services pick guard nodes currently, and we're simulating other ways to do it to see which one exposes itself to fewer relays—the fewer relays you are exposed to, the safer you are.
We’ve also been working on other security things as well. For instance, a series of papers and talks have abused the directory system of hidden services to try to estimate the activity of particular hidden services, or to launch denial-of-service attacks against hidden services.
We’re going to fix this by making it much harder for the attacker's nodes to become the responsible relay of a hidden service (say, catfacts) and be able to track uptime and usage information. We will use a "distributed random number generator"--many computers teaming up to generate a single, fresh unpredictable random number.
Another important thing we're doing is to make it impossible for a directory service to harvest addresses in the new design. If you don't know a hidden service address, then under the new system, you won't find it out just by hosting its HSDir entry.
There are also interesting performance things: We want to make .onion services scalable in large infrastructures like Facebook--we want high availability and better load balancing; we want to make it serious.
[Load balancing distributes the traffic load of a website to multiple servers so that no one server gets overloaded with all the users. Overloaded servers stop responding and create other problems. An attack that purposely overloads a website to cause it to stop responding is called a Denial of Service (DoS) attack. - Kate]
There are also onion services that don’t care to stay hidden, like Blockchain or Facebook; we can make those much faster, which is quite exciting.
Meanwhile Nick is working on a new encryption design--magic circuit crypto that will make it harder to do active confirmation attacks. [Nick Mathewson is the co-founder of the Tor Project and the chief architect of our software.] Active confirmation attacks are much more powerful than passive attacks, and we can do a better job at defending against them.
A particular type of confirmation attack that Nick's new crypto is going to solve is a "tagging attack"—Roger wrote a blog post about them years ago called, "One Cell Is Enough"—it was about how they work and how they are powerful.
4. Do you run an onion service yourself?
Yes, I do run onion services; I run an onion services on every box I have. I connect to the PC in my house from anywhere in the world through SSH—I connect to my onion service instead of my house IP. People can see my laptop accessing Tor but don’t know who I am or where I go.
Also, onion services have a property called NAT-punching; (NAT=Network Address Translation). NAT blocks incoming connections;it builds walls around you. Onion services have NAT punching and can penetrate a firewall. In my university campus, the firewall does not allow incoming connections to my SSH server, but with an onion service the firewall is irrelevant.
5. What is your favorite onion service that a nontechnical person might use?
I use ricochet for my peer to peer chatting--It has a very nice UI and works well.
6. Do you think it’s safe to run an onion service?
It depends on your adversary. I think onion services provide adequate security against most real life adversaries.
However, if a serious and highly motivated adversary were after me, I would not rely solely on the security of onion services. If your adversary can wiretap the whole Western Internet, or has a million dollar budget, and you only depend on hidden services for your anonymity then you should probably up your game. You can add more layers of anonymity by buying the servers you host your hidden service on anonymously (e.g. with bitcoin) so that even if they deanonymize you, they can't get your identity from the server. Also studying and actually understanding the Tor protocol and its threat model is essential practice if you are defending against motivated adversaries.
7. What onion services don’t exist yet that you would like to see?
Onion services right now are super-volatile; they may appear for three months and then they disappear. For example, there was a Twitter clone, Tor statusnet; it was quite fun--small but cozy. The guy or girl who was running it couldn’t do it any longer. So, goodbye! It would be very nice to have a Twitter clone in onion services. Everyone would be anonymous. Short messages by anonymous people would be an interesting thing.
I would like to see apps for mobile phones using onion services more—SnapChat over Tor, Tinder over Tor—using Orbot or whatever.
A good search engine for onion services. This volatility comes down to not having a search engine—you could have a great service, but only 500 sketchoids on the Internet might know about it.
Right now, hidden services are misty and hard to see, with the fog of war all around. A sophisticated search engine could highlight the nice things and the nice communities; those would get far more traffic and users and would stay up longer.
The second question is how you make things. For many people, it’s not easy to set up an onion service. You have to open Tor, hack some configuration files, and there's more.
We need a system where you double click, and bam, you have an onion service serving your blog. Griffin Boyce is developing a tool for this named Stormy. If we have a good search engine and a way for people to start up onion services easily, we will have a much nicer and more normal Internet in the onion space.
8. What is the biggest misconception about onion services?
People don't realize how many use cases there are for onion services or the inventive ways that people are using them already. Only a few onion services ever become well known and usually for the wrong reasons.
I think it ties back to the previous discussion--—the onion services we all enjoy have no way of getting to us. Right now, they are marooned on their island of hiddenness.
9. What is the biggest misconception about onion services development?
It’s a big and complex project—it’s building a network inside a network; building a thing inside a thing. But we are a tiny team. We need the resources and person power to do it.