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

[shadow]

Thank you for clarifying that. It totally makes sense to me now.


cheers shadow

On 26.02.2016 17:24, Alec Muffett wrote:
> 
> 
> On 26 February 2016 at 14:53, shadow <shadow at systemli.org
> <mailto: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

-- 
best regards | viele Gruesse, shadow at systemli.org

receive my key:
gpg --keyserver zimmermann.mayfirst.org --recv-keys 0x5C6B6ED4248C1F32


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-onions/attachments/20160308/fe6fdd5c/attachment.sig>