If/when will LE support .onion addresses?

Feature Requests
#1

There is some confusion about whether or not LE will support .onion addresses, and possibly .tor and .exit addresses in the future. The primary worries that I have seen mentioned are that

  1. Tor already end-to-end encrypts all traffic to onions and the identity of the onion is proved through it’s name, so there is no need to add an additional HTTPS layer.
  2. Since .onions are not registered with any domain registrar, LE cannot verify that you “own” a particular onion.
  3. For technical/limited-time-limited-functionality reasons, onionsites may not be supported at launch, or ever.

Can you comment on the validity and relevance of these three concerns, and let us know when onions will be supported? In particular, will they be supported at launch?

3 Likes
Privacy Badger blocks this site
Namecoin/DNSChain/.bit support
#2

Definitely not at launch, but it’s something we’ve thought about! We’ll be able to say more once we’ve launched and get to start planning out our future road map. As you say, there are special concerns with regards to validating .onion names.

2 Likes
#3

Well, I’m not a cryptographer, but it seems to me that if point 1 is true, then 2 must be false, since the owner of the domain has the private key that proves ownership of the domain and can use it to sign the certificate request. Which would appear to be a pointless exercise.

2 Likes
#4

I’ve been involved in several discussions about this issue on the tor-talk mailing list. There are some good reasons to try to run HTTPS to Tor hidden services, if possible. One is that the cryptography currently used with hidden services, although it is end-to-end, is somewhat out-of-date; the cryptographic algorithms and parameters used in browsers’ TLS implementations are more in line with current best practices. Another is that some browser policy mechanisms are active for HTTPS but not for HTTP; Alec Muffet, who was the main person responsible for the official Facebook Tor hidden service, has described some of those considerations in posts at

https://lists.torproject.org/pipermail/tor-talk/2015-August/038712.html

and

https://lists.torproject.org/pipermail/tor-talk/2015-August/038812.html

There are other logistical problems with issuing certs for .onion names which have to do with the CA/Browser Forum’s rules. In my understanding the biggest concern is not exactly “how to validate” these names, but rather how to guarantee that ICANN won’t create a separate “.onion” DNS domain, or that users won’t create internal “.onion” domains for their private intranets, which would result in a potential ambiguity about which site a particular cert was meant to refer to. Hopefully a way will be found to guarantee that the top-level domain “.onion” is never used in the domain name system, which will make its meaning unambiguous and reduce the concerns about having certificate authorities issue certificates for names within it.

Because of these concerns, Let’s Encrypt will have to wait and see what the process in the external entities like IETF and the CA/Browser Forum comes up with. There may be opportunities for interested people who are familiar with some of the technical and policies issues to get involved in the IETF efforts.

As @jsha said, Let’s Encrypt does not have the capacity to issue these certificates now, and we’ll have to examine the issue further in the future, hopefully following a clear statement from Internet governance entities that “.onion” should be reserved for Tor hidden services.

1 Like
#5

Please be careful!

1 is only correct for Tor hidden services, not for general Tor traffic. Tor does not encrypt your traffic end-to-end. From the Tor website.

“Tor will encrypt your traffic to and within the Tor network, but the encryption of your traffic to the final destination website depends upon on that website.”

Realistically, Tor on arbitrary websites without HTTPS or other encryption provides very little protection because your location and identity can be figured out from your data. HTTPS should be a very high priority for anyone concerned about anonymity.

1 Like
#6

@kerkeslager, we are talking about hidden services. All traffic to and from a hidden service is end-to-end encrypted. This is different from just using tor to browse the clearnet, where your potentially unencrypted traffic can be seen by an exit node. For browsing the clearnet, your warning should be carefully headed.

2 Likes
#7

Oh! My apologies! You’re absolutely correct! I still think this warning is important for people coming to this uninitiated, but I’ll edit to clarify.

#8

.onion is a special use TLD now! So it cannot be registered as a normal gTLD any more.
https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/

This document uses the Special-Use Domain Names registry to register the
’.onion’ Top Level Domain (TLD) for the Tor Network. This will allow hosts on
the ToR network to apply for and receive legitimate SSL Certificates.

I think that’s what you were waiting for…

3 Likes
#9

BTW from another topic a quote from @schoen:

Congratulations to the authors of the RFC, and thanks to the authors of
the earlier P2P Names Internet-Draft. I hope this leads the CA/B Forum
to agree that it’s appropriate for CAs to issue certs for .onion names
in the long run.

3 Likes
#10

Hi all I wanted to jump in here to provide some additional information. As you may know, the issuance of publicly-trusted SSL certificates is governed by the CA/B Forum. The biggest issue will be complying with whatever rules the CA/B Forum sets regarding .onion domains.

I am not a Tor user, so I have not followed the CA/B Forum’s actions on this very closely. But I believe that they had allowed the issuance of .onion domains, but only if they underwent a procedure similar to EV validation. Since Let’s Encrypt does not plan on performing manual validation, it would seem .onion domains wouldnt be something they could provide.

For those wanting to know more, they should read CA/B Forum Ballot 144. Unfortunately that has not yet been put on their website yet, so you would need to search their listserv archives to find it.

1 Like
#11

@vtlynch, I’m not clear on whether the CA/B Forum limited .onion certs to EV because of the questionable status of issuing for .onion at all (in terms of guaranteeing uniqueness of a name’s meaning), or because of the difficulty in specifying a validation method.

I hope that we’ll eventually be able to issue DV certs for .onion names, too.

1 Like
#12

Hi,

i think since two days now the status of ONION Domain is not no well Defined as an Spezial Domain.
http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

EV - did not make any sense for ONION Domain since hidden service normally mean that the person
does not want to be personally be known. For example woman help sites.

#13

However, it might make sense for a site such as http://facebookcorewwwi.onion. In fact, that’s a quite likely candidate for a DV (or higher?) certificate.

LE could issue a Proof-Of-Posession challenge for the hidden service’s private key as authorization for the domain.

1 Like
#14

Indeed, they already got an EV certificate under the current policy (which they were a major inspiration for).

#15

That’s a great idea. (This particular mechanism has never been used for DV before, but clearly it’s the gold standard technically for certificate issuance for .onion names.)

#16

I agree with issuing Proof-Of-Possession challenges for onion domains.

#17

Considering this new decision regarding .onion pseudo-TLD, would Let’s Encrypt be able to support .onion domains as a SAN where a site is accessible by both direct connect and by .onion, where the direct-connect domain would provide validation of domain ownership?

#18

@BFeely, probably not yet, because of industry rules that currently limit .onion certificates to EV, which Let’s Encrypt doesn’t issue at all.

#19

Really there are such <your bad word here> industry rules?
That’s disappointing…

#20

There are many reasons why having proper TLS/SSL certs setup for hidden services should be a priority. We run an non-profit private Tor-only e-mail service. It requires our members to connect to mail services (POP3/IMAP/SMTP) using TLS. Without valid .onion domain certs, our clients continue to get security warnings since even if we used lelantos.org certs… there would still be a mismatch when they connect to our hidden services.
This is but one example why certs are so important for .onion domains. Private key signing is quite robust and simple to implement.

I would appreciate any attention and energy you can commit to making this minor change to your software.

Sincerely,
Lelantos