Re: [tor-talk] Can someone please help me understand section 1.10 of the rendezvous spec

[Yaron Goland <yarong@xxxxxxxxxxxxx>]

It does make sense actually. In my case the reason I care is because of the TLS cert hole.

As is well known (and in fact Tor itself has a work around for it) the TLS handshake puts the client and server certs in the clear. Tor works around this, I believe, with the renegotiation trick where it negotiates a connection just with the server cert and then does a renegotiation over the encrypted connection to get the client cert. That way only the server cert is in the clear, not the client cert.

But in the project I'm working on (https://thali.codeplex.com) we want to protect the identities of both the client and the server. So we don't want the server's cert to be visible on the wire. To this end in our system peers (we are experimenting to see what it would take to build a peer to peer web) have two keys, a Tor hidden service key (e.g. onion address) and a separate identity key that is used to negotiate a SSL connection.

So a peer could have a constantly changing onion address while maintaining the same identity key. [1] So long as no one can see the TLS handshake then the connection between an onion address and the peer's identity key isn't easily discoverable.[2]

So Tor's end to end encryption for Tor hidden services is a real boon. It means when we negotiate the TLS mutual authentication connection over the Tor hidden service neither cert is ever in the clear and we get this for 'free'. That's really cool.

We are still in trouble for our ad-hoc networking and local networking cases (e.g. we have scenarios where users want to communicate directly without Tor) but those aren't as high priority and maybe we'll get lucky and the TLS 1.3 working group will fix the problem for us. If not, we have other work arounds (mostly using ephemeral certs with encrypted tokens in the SNI) but I'd rather not use them as they are fancy and hence unreliable.    

But Tor hidden services is our primary use case and it looks like it just made our life even simpler. Which is great!

Tor, the gift that keeps on giving. :)

        Yaron

[1] We actually wanted to use the identity key as the Tor hidden service key, especially for 'email' like scenarios where someone wants to receive communications from people they haven't previously talked to. But since Tor hidden services don't currently include any kind of cert chaining we couldn't take this route for security reasons. I did see that the draft for the next version of the rendezvous protocol may contain 'cert chain like' capabilities in order to support keep keys offline which is great!

[2] Right now any client that finds out the onion address can of course just connect and see what key gets presented over TLS. In some cases (like the email one above) that is a feature. But in others it's a bug. I have looked at the authentication features supported via Tor hidden services and they actually would work pretty well for us. In most of our scenarios a peer wouldn't expect connections from more than a few hundred other peers. But right now I'm just trying to get the basics working before I get fancy.
        
________________________________________
From: tor-talk <tor-talk-bounces@xxxxxxxxxxxxxxxxxxxx> on behalf of Matthew Finkel <matthew.finkel@xxxxxxxxx>
Sent: Tuesday, June 03, 2014 4:44 PM
To: tor-talk@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [tor-talk] Can someone please help me understand section 1.10 of the rendezvous spec

On Tue, Jun 03, 2014 at 07:47:29PM +0000, Yaron Goland wrote:
> I'm trying to understand section 1.10 of https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=rend-spec.txt
>
>
> It seems to say that Alice and Bob directly negotiate a shared symmetric key. Is that true? Does it mean that all communications between Alice and Bob, in the context of a Tor hidden service, are in fact encrypted end to end?
>
>
> I believe that https://www.torproject.org/docs/hidden-services.html.en confirms this point when it says "The rendezvous point simply relays (end-to-end encrypted) messages from client to service and vice versa."
>
>
> But this point is really critical for a threat model I'm building so I just want to make sure I've gotten things right. Could anyone confirm?


Hi Yaron,

The short answer is yes. This is how Alice and Bob establish a shared
secret key.

The longer answer is yes, section 1.10 describes how Alice (the client)
and Bob (the hidden service) establish shared secrets. After both Alice
and Bob possess the two respective halves of the Diffie-Hellman keys,
they use the shared secret and a key derivation function to expand the
key material into a byte sequence from which a 5-tuple is extracted (KH,
Df, Db, Kf, Kb). The first element (KH) is used to prove knowledge of
the shared secret, the second (Df) is used when computing the digest of
every cell from Alice to Bob, Db is the same but for cells from Bob to
Alice, Kf is the shared secret key used to {en,de}cipher cells from
Alice to Bob, and Kb is used to {en,de}cipher cells from Bob to Alice.
It sounds like these latter two keys, Kf and Kb, are what you are most
interested in.  Assuming the rendezvous point is unable to break the
security assumptions of the Diffie-Hellman handshake and the KDF is
secure, all messages sent between Alice and Bob are end-to-end
encrypted.

Does this make sense?

HTH,
Matt
--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk