Landmark for Hidden Services: .onion names reserved by the IETF

The Internet Engineering Task Force (IETF), the body that sets standards for the Internet, has formally recognized .onion names. We think that this is a small and important landmark in the movement to build privacy into the structure of the Internet. This standardization work for .onion is joint work between Facebook and the Tor Project amongst others in an effort to help secure users everywhere.

Over the last few years, The Tor Project has been working with other members of the Peer to Peer community led by Dr. Christian Grothoff, founder of the GNUnet project to register several Special-Use Domain Names. IETF name reservations are part of a lesser known process that ensures a registered Special-Use Domain Name will not become a Top Level Domain (TLD) to be sold by the Internet Corporation For Assigned Names and Numbers (ICANN). Special-Use Domain Names have special considerations documented as part of their registration. Some of these names may sound familiar, such as .local which is widely deployed by Apple and others for Multicast Domain Name Service (mDNS).

During our long journey which began in the Summer of Snowden, Alec Muffett and I were encouraged to split out .onion from the list of other peer to peer names and to make a separate draft to register .onion as a Special-Use Domain Name. In this draft we listed security and privacy considerations that we believe will help to protect end users from targeted and mass-surveillance. We're happy to say that the first name reservation was just published as RFC7686.

Our internet standard reflects on considerations for handling .onion names on the internet as well as officially reserving .onion as a Special-Use-Domain-Name with the Internet Assigned Numbers Authority (IANA). With this registration, it is should also be possible to buy Extended Validation (EV) SSL/TLS certificates for .onion services thanks to a recent decision by the Certification Authority Browser Forum. We hope that in the future we'll see easy to issue certificates from the Let's Encrypt project for .onion services. We also hope to see more Peer to Peer names such as .gnu registered as Special-Use-Domain-Names by the IETF.

It is now easier than ever to deploy, share and use Tor Hidden Services.

We greatly enjoyed our efforts with the IETF and plan to continue actively participate with the IETF in the future. We'd also like to thank everyone who helped with this process including but not limited to Mark Nottingham, Roger Dingledine, Linus Nordberg, Seth David Schoen, Leif Ryge, Helekin Wolf, Matthias Wachs and Dr. Christian Grothoff.


October 28, 2015


Good to know .onion is now officially recognized by the IETF, great progress!
But this "It is now easier than ever to deploy, share and use Tor Hidden Services." doesn't make sense to me, why would it be easier to deploy hidden services when it's recognized by the IETF?

Maybe your interpretation wasn't the one intended.

The statement is true regardless of this new development, thanks to continued incremental progress in onion services.

Why is that important, onion services are already end-to-end encrypted, and we can even trust that a onion service is even harder to "fake" or "MITM" than a regular SSL-certificate website.
I think it's very important that onion domains are reserved fr special use as Tor services, but I don't see why it is important to have SSL certificates...

Actually, Facebook et al wanted the https certificate primarily so that browsers would treat in-browser data the way it should for https sites (otherwise the browser has to be specially taught that "addresses ending in .onion are sort of like https sites"), and so that their server back-end would not need to have the ssme exceptions built-in (which would open it up to more bugs, maybe, too).

Read more about the Facebook .onion https part here:…

One problem I see with this"official recognition" of the .onion domain is that there is probably a central repository of hidden services lurking somewhere just waiting to be tapped by malicious actors( once the location of the repository has been located ) so while the service is to all intents and purposes decentralized it is also( unbeknown to the casual user) earmarked for very close scrutiny, expect an increase of anwelcome activity as a consequence.( but iIdo hope I'm wrong!! )

isn't hidden service name == (specific kind of) ip-number? in this case dns should support say ATOR record same as AAAA (for ipv6). so you can ask ATOR for (just as AAAA).
and anyway client can select dns server (tcp over tor?) so he can redefine say as localnet address (just as they do to .local)
in other words its enough to setup official tor DNS server and begin registering (public) hidden services - lets say chat.torproject.onion. thanks

If by "sponsored" you mean "there was a person who helped work on it, and he is an employee of Facebook", yes absolutely. Yay Alec.

If by "sponsored" you mean "Facebook gave money to Tor", alas no.


October 29, 2015


Do you have list of cert authorities that will provide ssl certs for .onion ?

You mean Digicert did Facebook's, he.

Maybe Let's Encrypt will do it? A couple of days ago I saw a Let's Encrypt certificate in the wild for the first time, the beta is already ongoing!

Currently the CAB forum has said that only EV certs can be issued for .onion addresses. Also, currently Let's Encrypt has promised never to issue an EV cert.

It's just a matter of time, and patience, and people putting energy into the standard process. I'm optimistic. You could help!

What was the CAB's rationale for not allowing DV certs as well? Couldn't they just be validated by signing the CSR with the onion key, or something along those lines?

How do we encourage/pressure the CAB to allow DV?

Obviously having FB pushing for EV helped, but presumably FB have no interest in helping with DV (they probably use EV for everything), so we're on our own and need to find some other way to get leverage, right?

why not tor/onion CA? i do not trust commercial CAs. Of course 'not a (very) good idea' but at least for mass users quite acceptible. just add it to browser's CAs list. (i have no problems with a small private CA for a long time).


October 29, 2015


Contratulations Tor team for .onion recognition. Future milestones, just as this one will be much easier to accomplish.

Keep at it.


October 29, 2015


Is it safe for a user to deploy a hidden service from home? Can one do that using Tor Browser Bundle?

It should be reasonably safe to run an onion service from home, yes. It really depends what your threat model is -- that is, what you're trying to protect against.

If I were running a Wikileaks submission server, I'd probably stick it on a computer somewhere else, so there's defense in depth.

But I regularly run a hidden service from my laptop, for example as part of the Ricochet program.

There is not currently support inside Tor Browser for setting up a hidden service. There have been a variety of tools over the years that aim to help you set one up, but none of them have really emerged as winners. The real trouble in each case is setting up the webserver in a way that doesn't leak info, since webservers are so complex.


October 30, 2015


Congrats for that.

However, guess what happened, when I clicked on the link to (using tor):

Error 1006 Ray ID: xxxxxxxxxxxxxxx • 2015-10-30 18:04:17 UTC
Access denied

What happened?
The owner of this website ( has banned your IP address (IP_of_exit_relay).


Oh, the irony ... Yeah, whatever ..

look how this spy guys are exposed... they all wants to get you. so you can extend Snowden's list of NSA controled companies. i wish i see some hi9dden service which will lists such websites...


October 31, 2015


can you reset the password for cypherpunks? make sure there's a way the pass wont get changed....


December 04, 2015


> There is not currently support inside Tor Browser for setting up a hidden service. There have been a variety of tools over the years that aim to help you set one up, but none of them have really emerged as winners. The real trouble in each case is setting up the webserver in a way that doesn't leak info, since webservers are so complex.

If it is technically feasible, I would like to see a fork of Tails which

o is specialized for running a HS (from home or a server room)

o is usable "out of the box" by anyone with a DVD read/write drive

o is designed to be run off a read-only DVD on a machine with no hard drive

o accepts content, written on another computer using ordinary Tails, which is added via an encrypted USB drive

This would require a new team of developers since the Tails team already has plenty of worthy tasks on their todo list.