[tor-onions] SSL certificates for hidden services/.onion domains

[Alec Muffett]

On 26 February 2016 at 14:53, shadow <shadow at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-onions/attachments/20160226/ed019497/attachment.html>