On Mon, Nov 17, 2014 at 05:48:26PM -0500, grarpamp wrote:
On Fri, Nov 14, 2014 at 12:08 PM, Tom Ritter tom@ritter.vg 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.