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

[grarpamp <grarpamp@xxxxxxxxx>]

On Tue, Nov 18, 2014 at 12:55 PM, George Kadianakis
<desnacked@xxxxxxxxxx> wrote:
> plans for any Tor modifications we want to do (for example, trusting
> self-signed certs signed by the HS identity key seem like a generally
> good idea).

If the HS pubkey and the onion CN were both in the cert, and signed
over by that same key all corresponding to the url the TBB is currently
attempting to validate, that would seem fine to me. No interaction with
the controller (which may not even be accessible [1]) needed to get the
HS descriptor (pubkey). Security is limited to 80-bits, or the future wider
proposal. It's also a TBB specific extension. All other browsers pointed
at socks5 somewhere will still rightly fail, unless adopted upstream
(which MSIE won't do) or via standards. Note that this is not 'turning off
the warnings for all .onion', it's recognizing that attestation of the HS key
is sufficient to show ownership of that service. Whereas under various
attacks a traditional selfsigned cert is not.

> M. Finkel:
> habit, where we're conditioning the younger generation to click-through,

It's suggested the right training is to teach the contexts in which they
should care... banking, email, accounts, etc... and then to in fact just
click through (everyday browsing) unless they're under a context where
they actually care. Even though you have the helmet, you train and care
wear a helmet for racing, not walking. The mandantory warnings are there
for people who care about their context, not those who don't.
My beef is that it requires more than one click in FF to get through.

Grandma panics and freezes because that's the response
you trained her to give. Grandma also didn't grow up with
a padlock icon on her iphone, she had rotary landline.
So forget about the grandma argument ok, that'll be gone in
a generation, till then it's cryptos who must give elder care.

> 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.

Again, you cannot break this by ignoring all of .onion.
If they want to be their own CA and give a root to their users,
that's their right and expectation of browser standards.
It's precisely the in house CA model commonly used
in corporate internals and other priviledged or separate cases.
It's their choice to opt in and supply the above HS pubkey exception
cert for bypass by TBB. Not TBB to remove capabilities from them.

> the hidden service's key can simply sign the CA cert or an intermidiate

Multiple services would need to include multiple HS keys
and sigs in the CA cert... it's literally a sizable mess and likely
not worth it when you can singly opt in or go private CA or
buy digicert on your own.

> I'm considering the feasibility of delegating verification to tor
> over the control port

See [1] above.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev