[cabfpub] .onion and .exit

[Jeremy Rowley]

I asked a couple of companies who have requested these types of certs about this and here is one reason for wanting a cert:

Our end goal here is to provide a secure and efficient mechanism for people to access our service via Tor.  Using a hidden-service and .onion address is the best method available to us.  Having a certificate for the .onion address that is rooted in a trusted authority makes everything both easier to use and more secure for all parties.  Adding these addresses to our main cert enables our service to assert the location of this hidden service in a way that ties it to us and makes it difficult for third-parties to compromise.

A not-insignificant portion of our users live in jurisdictions that are wary of and sometimes outright hostile to communication; they block access to us, they try to man-in-the-middle unsecured channels, and they occasionally attempt to MITM encrypted channels.  One method people use to access our service in these situations is Tor, connecting to Tor via an ephemeral node and then via a Tor exit node to us.  Running a Tor hidden service as an official front-end to our service enables us to protect those people who are using Tor to access our service from compromised exit nodes.  This hidden-service front-end also means that communication to our service via Tor does not take up any of the scarce exit bandwidth from the Tor network.

In this case, [customers] want the certificate to tie the service to the company so that users know exactly who is controlling the service. The cert is primarily to ensure that users are connecting to the correct service and that government actors aren't spoofing or MITM the service. The reason we want to add the .onion addresses to our certificate is that we believe the only way for us to truly secure the connection end-to-end is for us to present our service with a certified  .onion address and to rewrite all of our internal urls to be .onion addresses as well, a certificate for these .onion addresses means that we can secure the channel to the user from any compromised Tor nodes and present the user with the same level of security they would get when going to our main site directly via TLS.  We wish to add it to our main certificate as a set of SANs so that it is trivial for anyone on the internet to go to our main site, use their browser to examine the cert we present normally, and know what the correct .onion address is to reach us through the Tor network.  Tor lacks any sort of authoritative DNS system, with the .onion addresses serving as a self-certification mechanism.  This is not a bad thing normally, but it means that the only thing to bind a .onion address to a real service that exists outside of the Tor network is public consensus or a certificate.  Right now anyone could throw up a Tor hidden service that acted as a proxy to our service and claim it to either be official are a better/faster method than using a normal exit node and some people would believe them; once we start running our service we expect some to attempt this anyway.

Jeremy

-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org] 
Sent: Thursday, October 16, 2014 4:34 AM
To: Adam Langley; Jeremy Rowley
Cc: Phillip Hallam-Baker; CABFPub
Subject: Re: [cabfpub] .onion and .exit

On 14/10/14 19:01, Adam Langley wrote:
> The .onion names have transport security provided by Tor and thus 
> don't obviously need HTTPS certificates. You should certainly ask the 
> Tor folks before issuing for them. I'm not sure why .onion sites would 
> want HTTPS certificates.
> 
> If you do issue for them, the onion name itself is a hash of a public 
> key so a strong proof of possession should be pretty easy at least.
> 
> The .exit names are completely different and indicate a preferred exit 
> node, i.e. foo.com.bar.exit is foo.com via the exit called "bar". I 
> don't think HTTPS certificates should ever be issued for that and 
> .exit is deprecated by Tor in any case.

In addition to Adam's points: I suspect there are significant political issues in agreeing to formalize issuance of certs for non-IANA TLDs. It would be the equivalent of agreeing to issue SSL certs for alt roots:
http://www.wikiwand.com/en/Alternative_DNS_root
which of course leads to obvious problems when/if they overlap with IANA TLDs.

Gerv