Some news from the Onionspace, December 2025
This post is based on the transcript from the 2025 State of the Onion presentation.
Companion slides are available here.
Introduction
At Tor, it’s usually said that tech needs to be easier to use, and that is even more important for privacy-preserving technology.
A lot of our work this year was dedicated to make it easier to operate and maintain Onion Services.
In this post, we will walk you through how exactly we are accomplishing this.
But first, let’s do a quick refresher again on Onion Services, a communication technology for exchanging data using the Tor network, like we did last time:
Usually, whenever a Tor user is surfing around, their connection exits the Tor network at some point to reach a destination on the internet.
But with Onion Services, the communication from one point to another happens entirely inside the Tor network, all the time.
This brings a lot of benefits to users, service operators and the Tor network in general:
For users, it means additional privacy safeguards, such as improved anonymity and end-to-end encryption.
For service operators, it also brings censorship resistance and built-in protections against denial of service.
For the Tor network, Onion Services can alleviate the load on exit nodes, since it’s connections don’t need to reach the exits.
Roughly speaking, all that happens with two main pieces:
- The Onion Space.
- And the Rendezvous.
The Onion Space consists in all possible .onion addresses, and this number is huge, in the order of the estimated number of atoms in the galaxy!
Each .onion address is a big random string acting like an unique key used to authenticate and reach an Onion Service.
And the Rendezvous is a special protocol allowing a client to connect to a service announced by an Onion Address, which offers many interesting properties.
For those interested in the technical details, I recommend cve’s talk Onion Services: Design, Protocol and Implementation held at GPN23 back in June.
For those eager to know what’s going on recently, I bring some updates on what happened and what we’re planning to do.
Certificates
Let’s start with certificates.
We have good news to bring for those awaiting improvements on certificates for Onion Services!
Whenever you browse the internet, the connection between your computer and a service is usually encrypted, in a way that the safety of this communication happens through the verification of a special type of digital certificate.
With Onion Services, the connection is peer-to-peer encrypted by default, which means that no additional certificates are needed.
But having certificates easily available for Onion Services improves security and it’s also helpful for many use cases.
Improving the certificate functionality puts Onion Services in parity with the modern stack of web development and unleashes functionalities such as the faster connection protocol HTTP/2 and payment processing.
Thanks to the effort of community member Q and funding by OTF, certificate automation was finally elevated as an Internet Standard this year, with RFC 9799!
It’s not every day that there’s a new Onion Service standard approved by the Internet Engineering Task Force. This is a major achievement for Onion Services, so thank you Q for the hard work!
The next step is to work together with Certificate Authorities to ensure this specification is implemented and deployed, so it can benefit both Onion Service operators and users.
For operators, this will improve Onion Service maintainability and compatibility, by relying on the existing ACME standard.
For users, it will improve usability of onionsites, by making connections behave much more like regular websites, without some of the existing exceptions in the web browser interface and workflow.
Meanwhile, we improved our documentation on getting certificates using the current tools and recommended practices.
Onion Discovery Status
Certificates is not the only area for future improvements.
We are also ready to begin a long awaited research on Onion Services.
As I told last year, we want to have a way to provide human friendly addresses for Onion Services, improving usability in order to welcome millions to access our technology.
Currently, Onion Services are recognizable by their long addresses. A typical address looks like a big string ending in .onion, like archivep75mbjunhxc6x4j5mwjmomyxb573v42baldlqu56ruil2oiad.onion.
This is hard to type, and even harder to memorize.
We want to investigate existing proposals and also new, innovative ways to solve this problem.
A proof-of-concept was released five years ago, with an alias system in Tor Browser used by instances of the SecureDrop whistleblowing platform, introducing short and memorable addresses such as forbiddenstories.securedrop.tor.onion.
But this initial implementation does not scale and depends in some sort of bookmarking system hardcoded in applications.
That’s why we want to research alternatives: to have a better understanding on the pieces involved, the decision criteria to choose proposals as well as what should be done in terms of road mapping.
We are ready to to this research and are actively seeking for funding to do so.
Any and all donations support our overall work at the Tor Project. I want to thank the community for your ongoing support.
And if you are someone who is in a position to fund this specific project, here is your opportunity to make a difference.
Reach out to us, connect us with a potential funder, or lets start a conversation how to make Onion Services more user friendly and help millions access a free internet.
Growing Onion Services
I want to end this post with an additional reminder to everyone who wants to consider setting up an Onion Service site.
So who are the best fit for onionsites?
Are you a news outlet seeking to connect with people in censored regions?
Are you a nonprofit seeking to share critical information to help people in need that are living in a country under heavy surveillance?
Are you open source project that wants stay fully anonymous to create a privacy by design tool to help us defend human rights?
Onion Services are currently the most censorship resistant technology out there because it’s the harder one for a malicious internet provider or authoritarian government to detect the connection or block access to it.
Onion Services are easier than ever to setup but we can still do better.
Right now you will still need IT staff to install and manage an onionsite, but nobody needs to be a Tor expert for that.
We also provide user support and have a helpful community.
We are striving for excellence, and in the long run we expect to make Onion Services tools even easier to use and maintain. We’re already working on that.
Last year, the Internet Archive set their onionsite, and we were told how much effort it took even for system engineering experts to do the setup.
We took that feedback very seriously and we improved or tools and documentation, so now it’s possible to setup an onionsite with just a few commands using Onionspray, a system allowing to create Onion Services out of existing websites.
It’s also worth mentioning the fast-paced Onion Service development in Arti, which has implemented a number of features and has more underway, as well as two recent initiatives to automate Onion Service operation:
-
Thanks to the Mediapart newspaper and the work of Tor community member zoug, it’s now possible to deploy and maintain Onionspray using the Ansible automation system, which is very popular among system administrators.
-
We now have experimental container images for Onion Services, based on both the legacy C Tor server and Arti, the new Rust Tor Implementation. These images have everything needed to run .onion endpoints without external dependencies, and can run on servers supporting containers.
All this and much more you can find in our Ecosystem Documentation!