Re: [tor-dev] Of CA-signed certs and .onion URIs

[Matthew Finkel <matthew.finkel@xxxxxxxxx>]

On Mon, Nov 17, 2014 at 05:48:26PM -0500, grarpamp wrote:
> On Fri, Nov 14, 2014 at 12:08 PM, Tom Ritter <tom@xxxxxxxxx> wrote:
> > a) Eliminate self-signed certificate errors when browsing https:// on
> > an onion site
> 
> No, please don't. Browsers throw cert errors for good reasons.
> If you don't want to deal with it, just click accept or otherwise
> pin them out in your trust store. Blind acceptance of certs just
> because the TLD says .onion is just as dumb as trusting .com.
> And if Joe and Jane's cluster of services wishes to publish a CA or
> any other form of trustweb you're going to break that too. Don't do that.
> If you don't think trust has the similar uses in anon networks as
> on clearnet, or will never appear there, you need to open your eyes.

Well, I think I'm significantly less opposed to this idea than you seem
to be. I also think, sadly, this idea conflates two distinct issues.

Do you know what happens when my grandmother sees a certificate warning?
She panics and freezes. I expect this happens more often than people
ignorantly clicking through the warning. This also may be a generational
habit, where we're conditioning the younger generation to click-through,
while the older generations are still worried about breaking their
computer. In either case, I think this is mostly irrelevant for what
we're trying to accomplish.

Eliminating self-signed certificate errors when connecting to hidden
service sites will be a significant usability improvement. Personally,
I will probably never pay for a CA signed cert for my hidden service,
but I also want my grandmother to have a pleasant experience when she
visits the site. How can we solve this dilemma?

Question 1: What is my cert trying to prove/what problem is my cert
            trying to solve?

In reality, if I only use a self-signed cert it proves nothing, but it
does provides another layer of encryption. Defense-in-depth, as Jacob
said. This is the only thing I can provide. There is no assertion
that the hidden service connected to *my* website.

Question 2: What if Joe and Jane publish a CA or <blah>?

They are atypical and all users will still received a certificate
validation error when they try connecting to the cluster because the
CA isn't...trusted. This error message does not solve the problem. It
is scary and breaks the usability of (potentially) secure
communication. We should absolutely fail closed, but we should make
the common-case usable.

Question 3: How do we solve this problem?

I think step 1 is removing the PKI TTP. The CA is a hazard and
complicates the problem. The proposed solution with the most potential
is signing the cert with the hidden service's key, thus coupling the
two and certifying the TLS cert. Cross-certification is more difficult,
and arguably out-of-scope for Tor. With the next-gen service
implementation coming soon, it may be helpful to consider how we can
integrate this functionality and how difficult it will be to verify
an ed25519 sig in Tor Browser.

I'm considering the feasibility of delegating verification to tor
over the control port, but this is quite risky and it may be better
to handle this directly in the browser. Not sure.

I admit, it may be useful to use a CA in some situations, but then
the hidden service's key can simply sign the CA cert or an intermidiate
cert, instead of signing each leaf cert directly. In either case, the
end result is the same.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev