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.]
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. Donate today!
The topic for today is electronic money. The blockchain is pretty hot right now! Bitcoin, dogecoin, ethereum, zcash you name it... Cryptocurencies have grown from e-toys to globally recognized systems by facilitating free and borderless trade, no bank fees and improved privacy.
You are reading the Tor blog, so let's focus on the privacy and anonymity part. Could cryptocurrencies claim that they provide privacy if Tor was not around to give strong transport-layer anonymity?
To visualize this, let's go through just a few ways Tor is used around the cryptocurrency ecosystem. We will mainly focus on Bitcoin, but the same applies to most blockchain-based cryptocurrencies:
Tor provides privacy to cryptocurrency transactions!
Let's imagine that Alice wants to buy a ticket for Torconf, the best (fictional) conference on computer anonymity. She wants to buy the ticket with Bitcoin so that she does not reveal her interests to her bank or her identity to the conference organizers. To buy the ticket with Bitcoin, she needs to perform a Bitcoin transaction.
Bitcoin transactions work by Alice broadcasting her transaction to a few Bitcoin supernodes. Those nodes then propagate the transaction further to the rest of the Bitcoin network until it becomes recognized. If Alice did not use Tor to conduct her transaction, those initial supernodes trivially learn the IP address of Alice. Furthermore, since the Bitcoin blockchain is a public log of transactions, analysts could match her newest transaction with her previous transactions and just follow the money trail. These are just some of the many well known privacy risks of Bitcoin, and companies have been collecting and selling social graph analytics of the Bitcoin blockchain for years now...
Given the above threats, it should be no surprise that most Bitcoin clients give the option to their users to perform transactions over the Tor network. By routing traffic over Tor, no one learns the origin IP address of Alice when she buys her Torconf ticket.
Furthermore, even the hottest and newest cryptocurrencies (like Zcash) that provide transaction anonymity as a fundamental security property still benefit from Tor's transport-layer anonymity to actually anonymize the networking part of the Zcash transaction.
We feel that Tor has tremendously helped the cryptocurrency community to grow just by providing transport-layer anonymity to transactions! Also, please remember that maintaining anonymity is not an easy task, so always be up-to-date on the latest security news depending on your threat model.
Tor secures cryptocurrency networks!
Apart from users performing anonymous Bitcoin transactions, the Bitcoin network itself uses Tor to increase its defenses. Since last year, the Bitcoin core project has integrated Tor onion services to their core network daemon. If Tor is installed in the system, Bitcoin will automatically create an onion service and act as a Bitcoin node over Tor to avoid leaking the real IP address of the node. This provides greater network resilience and protection against targeted attacks to Bitcoin nodes. You can see that there are hundreds of Tor bitcoin nodes. Zcash and other cryptocurrencies have followed the same path.
Furthermore, many mining pools advertise onion service support for their miners. Bitcoin infrastructure has been a target of hackers for a while, and virgin blocks are more and more valuable, so having anonymity as a miner is a desirable security property.
Tor protects the wider cryptocurrency ecosystem!
If you take a look around the Bitcoin world, you will notice that Tor support is advertised by all sorts of websites and services! Most bitcoin-related websites have onion sites that people can visit over Tor: for example, blockchain.info has been running a popular Tor onion service for its users. Most Bitcoin tumbler services also work over Tor onion services. Same goes for websites and forums offering help with Bitcoin. This is obviously done because the Bitcoin community has a great appreciation and need for privacy.
Tor is proud to have helped the cryptocurrency community grow over the years. We believe that electronic currencies can be a powerful tool for social change, but also a great scientific research area with results that can benefit other areas, like secure electronic voting, consensus algorithms, append-only data structures and secure name systems.
Have a good day :)
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!
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.
Riseup.net was started back in 1999 after the WTO protests in Seattle. They provide online communication tools, including email, chat, file uploads and collaborative platforms for people and groups working on liberatory social change. Riseup is a project to create democratic alternatives and to practice self-determination through the control of secure means of communication.
The Riseup collective is made up of many "birds" who believe it is vital that essential communication infrastructure be controlled by movement organizations and not by corporations or governments.
They strive to keep mail as secure and private as possible. They do not log your IP address. (Most services keep detailed records of every machine that connects to their servers. Riseup only keeps information that cannot be used to uniquely identify your machine). All of your data, including your mail, is stored by riseup.net in encrypted form. They work hard to keep their servers secure and well defended against any malicious attack. They do not share any of their user data with anyone. They actively fight all attempts to subpoena or otherwise acquire any user information or logs. They do not read, search, or process any of your incoming or outgoing mail, other than by automatic means to protect you from viruses and spam or when directed to do so by you when troubleshooting.
Some of the Riseup birds work tirelessly on building secure email infrastructure, one of them runs longclaw, one of our amazing directory authorities, and all of them are dedicated to building a better Internet—and thus, incidentally, a better world. Oh, and they also run two fast Tor exit nodes, wagtail and pipit.
We also can't thank them enough for writing this Onion Service Best Practices Guide, helping countless users and services around the Internet to be more secure, and truly making everyone not part of a DarkWeb but rather a SecureWeb (tm).
We hope we can continue this close relationship with Riseup. So many Tor users around the world depend on them for protection. Please visit our bird friends at Riseup and support their critical work!
Thank you for reading, and soon enjoy not being in 2016 anymore! :)
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.
The Internet was made for humans to communicate with each other! Even though Internet calls over video and audio are totally possible nowadays, people still enjoy sending texts to each other due to their asynchronous, permanent and casual nature. To understand how important these instant messaging systems are, just check the user growth of systems like WeChat, WhatsApp, etc.
Unfortunately, all these major mainstream messaging systems belong to huge companies whose money comes from advertising and selling the data and metadata of their users.
The good news here is that in the past couple of years, there has been great progress in protecting users' data by employing end-to-end encryption using the Signal protocol. The bad news is that there has still been absolutely no progress in protecting the metadata and location information of users by these mainstream platforms.
Case in point, since most instant messaging systems are not anonymous, they get to learn the full location history of their users through the users' IP address history. Also, all major chat systems require a social media account or a phone number, which is simply impossible for some people, and it also makes it hard to create anonymous or burner accounts for everyone. It also makes you searchable and targettable by people who happen to know your phone number.
In this blog post, we showcase a few open-source text messaging tools that provide location privacy and additional security to their users by using Tor as a default. All of them are free and open source, so feel free to experiment!
Ricochet is an anonymous instant messaging tool that hides metadata by using Tor. It's got a slick UI and works on Windows, Linux and Mac OS X.
In the Ricochet protocol, each user is a Tor onion service. By utilizing onion services, the protocol achieves strong anonymity for its users. And because of its decentralized nature, it's impossible for attackers to censor it by taking down a single server.
Ricochet is designed with UX in mind, so it's easily usable even by people who don't understand how Tor works.
If you happen to only use mobile platforms (like most of the world these days), Chatsecure is an app that you should check out! It works for both Android and iOS, and it allows you to connect to XMPP servers to communicate over encrypted OTR chat. This means that you can also use it to connect to other XMPP-enabled messaging systems like Facebook chat and Google Talk.
It's developed by the Guardian Project, and it's a part of their software suite for private communications that includes Orbot and Orfox. Stay tuned on our blog for more information about this software family later this December!
And now for further excitement, let's get into the more experimental sections of the secure messaging space!
Pond is an anonymous instant messaging tool with various sophisticated security properties that is capable of hiding even the metadata of its users.
The protocol is designed in such a way that even a nasty attacker who is constantly monitoring your Internet connection will have a very hard time figuring out when you actually send and receive Pond messages, even if she conducts statistical analysis of your traffic patterns. Smoke and mirrors you might say, but if you like protocols, we invite you to check out the Pond protocol specs.
Unfortunately, Pond is a side-project, and due to lack of free time, the project is not currently actively being developed, even though there is still a community of users. It only works on Linux, and it has a GUI interface.
Briar is an experimental P2P messaging system that is currently in private beta. It targets mobile users and is closely integrated with Tor onion services.
The Briar protocol is fully decentralized, and all communication is end-to-end encrypted. It aims to be highly resilient against network failures, and so it can also function over Bluetooth or WiFi. Furthermore, it attempts to hide the social graph of its users by keeping the user contact list on the client side.
As you can see, there have been multiple efforts for private and metadata-hiding communication over the past years. Some of these projects are supposed to be used on top of already existing chat frameworks, whereas others aim to create their own ecosystems.
Of course, the research realm of secure messaging is far from complete; it's just getting started. From improving the UX to adding new security properties, this field needs further thinking all around.
For example, secure multiparty messaging is a very important upcoming field that studies how the protocols above that are designed for 1-to-1 communication can scale to hundreds of clients talking at the same time while maintaining their security properties.
Furthermore, as global surveillance is growing, we better understand the importance of hiding metadata from network attackers. Only now are we starting to grasp the importance of security properties like obfuscating communication patterns, hiding the users' social graph and letting users choose when to reveal their online presence.
Tor is extremely interested in the instant messaging space, and we are always on the lookout for innovative developments and interesting messaging projects. We have deep gratitude to all of the people who have helped to push the field of secure messaging forward, and we hope to enable them in the future to provide anonymous communication tools!
Donate and we will make it happen! :)
The Ahmia project
Onion services are used by thousands of people every day, yet they remain as elusive as ever. There is no central repository of onion sites, and there are no great ways to find the content you are looking for. We feel that this "foggy situation" severely impacts the user experience of onion services and hence also impedes their deployment and acceptance by the general public. It's easy to dismiss the onionspace as smelly if you only read media articles about the onion sites that stink the most.
How is one supposed to navigate in the onionspace if there is no map?
On the "normal Internet," people are used to using search engines to find the content they are looking for: blogs, shops, educational resources, cat pictures. Search engines act as streetlights on the dark alleyways of the Internet; allowing people to navigate and visit the places they want.
However in the onionspace, search engines are not well established, and finding the right content is much harder. For years people have resorted to various DIY solutions for listing and finding onion addresses, but none of those solutions is particularly pleasant or complete.
Imagine Alice wants to start a blog about her cats on the onionspace. There is no good place for Alice to list her onion address so that other people can find it. Without a good search engine, it's hard for other cat fans to find her website and start building a community.
How is one supposed to catch 'em all if we don't know how many there are?
Hence, there is no better time to introduce Ahmia! Ahmia is a search engine for onion sites. The Ahmia project has been around for years, and it's been collecting public onion addresses and indexing them so that users can search for the content they are looking for.
Ahmia's indexing technology is improving, and the quality of the search results has gotten much better over the past year. Ahmia also provides an easy way for onion service operators to register their own onion sites with the search engine. Ahmia's onion site is here.
Juha Nurmi, the lead Ahmia developer, is still actively involved with the project, however writing a low-budget search engine is not an easy job! Crawling the Internet requires heavy infrastructure and is technically complicated. Discovering onion links means searching in the deepest corners of both the normal Internet and the onionspace. Ahmia is always looking for more volunteers and sources of funding! Two years ago, Tor supported Ahmia by working together in Google Summer of Code 2014.
How is one supposed to walk around if the fog machine is on?
Finally and closing with a healthy dose of paranoia, we need to remember that centralized search engines might be a temporary solution for now, but they are never the end goal. Centralized services should be avoided in high-security systems like anonymity networks, and we should always strive to build decentralized systems and to research alternative ways to make anonymity systems more usable. There is lots of work to be done.
Donate and get involved!
Thank you for reading and enjoy Monday!
apt-transport-tor and Debian onions
Did you know that when you're using Debian, you can configure your operating system package installs and updates to route through Tor?
Doing updates via Tor provides some really compelling security properties. One of the big benefits is that an attacker can't target you for a malicious update: even if they manage to steal some package signing keys and break into the update server and replace packages, they still can't tell that it's you asking for the update. So if they want to be sure you get the malicious update, they're forced to attack everybody who updates, which means a really noisy attack that is much more likely to get noticed. This anonymity goal is one of the main reasons that Tor Browser does its updates over Tor as well.
Another big feature of updating via Tor is that the package repository, or somebody watching it, can't track what programs you've installed. Similarly, somebody spying on your Internet connection will have a tougher time learning which packages you fetch (though this part of the protection is not as strong, since maybe they can count bytes or something and guess).
As Debian's blog puts it:
"The freedom to use open source software may be compromised when access to that software is monitored, logged, limited, prevented, or prohibited. As a community, we acknowledge that users should not feel that their every action is trackable or observable by others. Consequently, we are pleased to announce that we have started making several of the various web services provided by both Debian and Tor available via onion services."
Not showing the world what packages you fetch is good common-sense data hygiene, but it can also provide safety when you're updating a package due to a security vulnerability, and you don't want people to learn that you're running a vulnerable version right now.
How does it work from a technical perspective? The apt-transport-tor deb package introduces a new "tor+http" transport that you can use in your /etc/apt/sources.list file -- so while before you would typically list a Debian package repository as being an "http" address, now you can list it as being a "tor+http" address. Debian has its own official onion addresses for its package repositories, along with onion addresses for many of its other sites and services — and they even use Donncha's OnionBalance tool to provide redundancy and scaling. (Also, since the nice person who helps run Debian's infrastructure also helps to run our infrastructure, that means we now have onion addresses for many of Tor's sites and services too!)
You can configure your Debian system to update via Tor by following the directions at the bottom of the Debian blog post. A growing number of privacy-oriented Debian derivatives, including Tails, use apt-transport-tor as their default way of doing updates, and we think that's a great and important trend.
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 :)
We, the Debian project and the Tor project are enabling Tor onion services for several of our sites. These sites can now be reached without leaving the Tor network, providing a new option for securely connecting to resources provided by Debian and Tor.
The freedom to use open source software may be compromised when access to that software is monitored, logged, limited, prevented, or prohibited. As a community, we acknowledge that users should not feel that their every action is trackable or observable by others. Consequently, we are pleased to announce that we have started making several of the various web services provided by both Debian and Tor available via onion services.
While onion services can be used to conceal the network location of the machine providing the service, this is not the goal here. Instead, we employ onion services because they provide end-to-end integrity and confidentiality, and they authenticate the onion service end point.
For instance, when users connect to the onion service running at http://sejnfjrq6szgca7v.onion/ using a Tor-enabled browser such as the TorBrowser, they can be certain that their connection to the Debian website cannot be read or modified by third parties, and that the website that they are visiting is indeed the Debian website. In a sense, this is similar to what using HTTPS provides. However, crucially, onion services do not rely on third-party certificate authorities (CAs). Instead, the onion service name cryptographically authenticates its cryptographic key.
In addition to the Tor and Debian websites, the Debian FTP and the Debian Security archives are available from .onion addresses, enabling Debian users to update their systems using only Tor connections. With the apt-transport-tor package installed, the following three lines can replace the normal debian mirror entries in the apt configuration file (
deb tor+http://vwakviie2ienjx6t.onion/debian jessie main
deb tor+http://vwakviie2ienjx6t.onion/debian jessie-updates main
deb tor+http://sgvtcaew4bxjd7ln.onion/debian-security jessie/updates main
Likewise, Tor's Debian package repository is available from an onion service :
deb tor+http://sdscoq7snqtznauu.onion/torproject.org jessie main
Lists of several other new onion services offered by Debian and Tor are available from https://onion.debian.org and https://onion.torproject.org respectively. We expect to expand these lists in the near future to cover even more of Debian's and Tor's services.
We’ve been speaking to journalists who are curious about a HotPETS 2016 talk from last week: the HOnions: Towards Detection and Identification of Misbehaving Tor HSDirs research paper conducted by our colleagues at Northeastern University. Here's a short explanation, written by Donncha and Roger.
Internally, Tor has a system for identifying bad relays. When we find a bad relay, we throw it out of the network.
But our techniques for finding bad relays aren't perfect, so it's good that there are other researchers also working on this problem. Acting independently, we had already detected and removed many of the suspicious relays that these researchers have found.
The researchers have sent us a list of the other relays that they found, and we're currently working on confirming that they are bad. (This is tougher than it sounds, since the technique used by the other research group only detects that relays *might* be bad, so we don't know which ones to blame for sure.)
It's especially great to have this other research group working on this topic, since their technique for detecting bad relays is different from our technique, and that means better coverage.
As far as we can tell, the misbehaving relays' goal in this case is just to discover onion addresses that they wouldn't be able to learn other ways—they aren't able to identify the IP addresses of hosts or visitors to Tor hidden services.
The authors here are not trying to discover new onion addresses. They are trying to detect other people who are learning about onion addresses by running bad HSDirs/relays.
This activity only allows attackers to discover new onion addresses. It does not impact the anonymity of hidden services or hidden service clients.
We have known about and been defending against this situation for quite some time. The issue will be resolved more thoroughly with the next-generation hidden services design. Check out our blog post, Mission: Montreal!