Hi Ron!

I know that a select few public SSL certificates have been issued for .onion domains, but I understand that the status of those certs is tenuous.

Apologies for contradicting you, but there is nothing "tenuous" about Onion certificates.

They are fully fledged, official certificates, and the domain-related issues have all been solved.

The open issue, if any, is that such certificates are "EV"-style, and as such are only really open to companies because background checks.

I outline the issue here: http://dropsafe.crypticide.com/article/11697 - take note especially of the comments, which leads to some commentary on the relevant maillist from key members of CABForum.

Has anyone considered implementing a custom certificate service just for .onions? If the Tor Browser shipped with an additional root certificate, that certificate could be used to sign .onion domains.

My feelings regards such a proposal are "that would work, yes, but that would put Onions into a 'SSL Ghetto' and inhibit adoption of Onion technologies by 'normal' browsers".

Further than that, I believe that the proper approach is to obtain CABForum backing for DV, AV or IV certificates for Onion sites. See http://dropsafe.crypticide.com/article/11697 for explanation of unfamiliar acronyms.

Proof of ownership of .onion domains is relatively easy to ascertain.

Ballot-144 https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/ describes two methods to do so, but in truth at least one of them is not as good as I would like to see.

Note also the concerns expressed by Ryan Sleevi at https://cabforum.org/pipermail/public/2015-November/006213.html

These are concerns which must be addressed (or constructively negated) to _some_ extent, to pursue Onion DV certs a-la LetsEncrypt.

I haven't looked at the problem in detail, but I believe that a fully-automated process could issue certs for arbitrary .onion domains encrypted with the domain's public key. Only the domain owner would have the private key to decrypt and install the certificate.

Yes, that could happen. That's one of the methods suggested in Ballot-144. The CABForum have somewhat justified concerns with that mechanism, mostly regards revocation, Onion certificate theft, and SHA hash-collisions.

The Certificate/CABForum world has grown up in partnership with capabilities like taking domain-name dispute resolution to some kind of arbiter, but Onionspace lacks such - onions are much more binary, hinging upon possession of the Onion key.

This means that CABForum needs gentle introduction to wholesale change. The establishment of more 'official' SSL/EV keys in Onionspace will make an argument for further growth.

torproject.orghttp://torproject.org would have to be willing to ship the Tor Browser with the necessary root certificate, but the root would not need the blessing of the CA/Browser Forum or any other authority figure.

In summary, I repeat, I feel this would address a short-term, TorBrowserBundle need, but cause harm elsewhere to the greater world's adoption of Onions.

-a

Can anyone explain the advantages of .onion certs?

As far as I understand the onionservice architecture, the traffic between the onion service and the client is EndtoEnd-encrypted?

I thought it was a political goal to get recognized (thanks for doing that) and a userinterface/experience goal to get this shiny green bar, when connecting to an .onion service.

cheers shadow

On 22.02.2016 17:12, Ron Risley wrote:

...

On Feb 22, 2016, at 06:18, Alec Muffett alecm@fb.com wrote:

Apologies for contradicting you, but there is nothing "tenuous" about Onion certificates.

I don't mind being contradicted. I was responding to articles like this one, which said "these .onion certificates are considered internal name certificates. The CA/Browser Forum has deprecated the use of public SSL Certificates for internal names and they will no longer be allowed after November 1, 2015. "

https://blog.digicert.com/the-current-state-of-onion-certificates-and-what-h...

I realize that situation has changed in the past year, with the IETF's official recognition of the .onion space.

Thanks for the references. They'll help me get up to speed on the current state of things.

Though I agree about the risk of ghettoization of the .onion space, I also see an opportunity here to avoid some of the pitfalls of the current SSL certificate trust model, specifically with regards to rogue authorities and stolen/forged signing keys.

Again, thanks...

--Ron _______________________________________________ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions

Thanks for this brief explanation,

so the main goal of SSL addresses the problem of impersonation.

Isn't there an easier way to implement that somehow in the Tor code, than to rely on the (kind of broken) SSL system? But that would only address point 1), 2), 3) and 6)

cheers shadow

On 25.02.2016 17:17, Alec Muffett wrote:

...

On Feb 25, 2016, at 15:33, shadow shadow@systemli.org wrote:

Can anyone explain the advantages of .onion certs?

Having SSL Certificates for Onion addresses can help answer questions like:

1. "how do I know that this onion address is run by the *real* <insert-company-name>?"

2. "how do I know that <www-onion-address> and <cdn-onion-address> are run by the same <organisation>?"

3. "what can I do about <bad people> who set up a look-alike phishing onion site and try fooling people into thinking it's mine?"

4. "my existing website codebase relies heavily upon 'secure cookies' which can only go over HTTPS; how can I launch an onion site without doing a lot of expensive refactoring of my code merely to support an experiment with Tor?"

5. "new features in upcoming browsers are going to be locked to HTTPS access - some already are, eg: webcam access - how can i futureproof?"

And because Ballot-144 was thought about by a bunch of sensible people:

6. "Onion SSL Certificates are EV-only. But I need a wildcard certificate! Oh, wait, Onion-EV certificates are wildcard-enabled? Cool!"

   -a

---

tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions

Thank you for clarifying that. It totally makes sense to me now.

cheers shadow

On 26.02.2016 17:24, Alec Muffett wrote:

On 26 February 2016 at 14:53, shadow <shadow@systemli.org mailto:shadow@systemli.org> wrote:

Thanks for this brief explanation,

so the main goal of SSL addresses the problem of impersonation.

Actually, from my perspective, to focus on a "main goal" (rather than a primary benefit) and then question it, doesn't really seem to make sense.

You say "(kind of broken) SSL system" - any yes, there are many criticisms that can be laid at SSL's feet, and many flaws; but when you're building a secure system it's a matter of synthesis - it's a bit like cooking, you add the ingredients which make sense for what you want to achieve.

And re: point 4, for instance, when you have many megabytes of code which expect to be dealing with HTTPS Secure Cookies, perhaps *that* is more important to you than point 1; or perhaps point 5 is.

But let me put that argument to one side for the moment, and address your question as-stated:

Isn't there an easier way to implement that somehow in the Tor code,
than to rely on the (kind of broken) SSL system? But that would only
address point 1), 2), 3) and 6

The answer to that is "maybe"; there's an informative comparison here to be made with IPsec Authentication Headers*, commonly known as "AH"; it provides an authentication framework but leaves you (again) to bootstrap your notion of "identity"; you have to work out your own preferred solution for host identity and validation.

Also: in the traditional internet we're used to the idea of "1 IP Address => 1+ Websites"; you can run a bunch of different websites with different domain names on a single machine with a single IP address, but in that model IPsec fails** because it authenticates *IP addresses* rather than DNS domain names.

In Tor we traverse almost all boundaries between ISO Layer 3 and 7 - the Layer-3-alike Onion address provides AH-like authentication but is as visible to the user as a Layer 6? (7?) DNS domain names; and it's arguable that Onion site HSDirs are their own version of Layer-2 ARP, likewise. Tor is basically a separate networking stack to TCP/IP, and should maybe be treated as one - but this raises the question: "What <element of the network stack> are you trying to authenticate/validate, in some proposed SSL-replacement?"

And that is a question, the answer to which should be up to the implementer:

• People who want to use Tor like a VPN/IPSec Replacement may put trust

in Onions to assure the endpoint they are connecting to.

• People who want to use Tor as a SSL Replacement can amend their

browser to treat onionsites as equivalents to HTTPS; but then they have to change all the other software in the world to bring it into line / know that "onion == SSL" else the sites will misbehave; but practically this is unlikely to happen.

Thus the status quo: treat Tor like a TCP circuit in a different address space, and permit people to put whatever they want over it. Including SSL, if they wish. Or an alternative, if they wish to innovate.

-a

• http://www.tcpipguide.com/free/t_IPSecAuthenticationHeaderAH.htm

** Aside: with the emergence of IP6 we now have enough space again for "1 IP Address === 1 Website", so maybe it's time elsewhere for an IPsec reboot?

-- http://dropsafe.crypticide.com/aboutalecm