On 26 February 2016 at 14:53, shadow 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?