Re: [tor-talk] Fwd: [Full-disclosure] tor vulnerabilities?

[Nick Mathewson <nickm@xxxxxxxxxxxx>]

On Sat, Jun 29, 2013 at 5:53 PM, Nick Mathewson <nickm@xxxxxxxxxxxx> wrote:
> On Sat, Jun 29, 2013 at 4:43 PM, Cool Hand Luke
> <coolhandluke@xxxxxxxxxxxxxxxx> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> the below text was posted to pastebin.com (see original e-mail to the
>> full-disclosure list at the end of this message).
>>
>>
>> - ----- BEGIN PASTEBIN -----
>> Tor LOL:
>>
>> directory authorities are the point of contact for clients to locate
>> relays/exit nodes/guard nodes/etc. This is determined by a consensus
>> document that goes through an elaborate process to ensure its integrity
>> and cause bad directory authorities to be identified also via consensus.
>>
>> However, Tor developers are not the quickest lot, and this is basically
>> the only document that they serve that has integrity control on it. Most
>> interestingly, the public keys for every other node in the network is
>> served without any form of signature or other form of integrity control.
>>
>> As such, a rogue directory authority, which anyone can be simply with a
>> configuration option and an IP, can introduce path bias and other such
>> tricks by serving the wrong keys for relays/guards/exits that it doesnt
>> control. This can result in essentially directing clients through the
>> network by causing decryption failures, thereby allowing determination
>> of the source and end-point of a given tor connection with little more
>> than a couple relays and some rogue directory authorities. Moreover, it
>> can use the simple-minded metrics made to identify rogue guard nodes and
>> couple that together with the behavior of public key cryptography to
>> actually cause legitimate guard nodes to be flagged as having excessive
>> extend cell failures causing it ultimately to be marked as bad.
>
> I think this guy is confused.  I tried to tell him as much when he
> twittered at me last night; you can see more or less the full record
> if you look at the @nickm_tors from last night.
>
>
> tl;dr: relay onion keys are indeed authenticated by the consensus
> document.

And let me try to explain this a little more, and give some background
about how keys are supposed to be authenticated in the current
("microdescriptor") directory design.

There are a few directory authorities. (You *can't* be one in any
meaningful way just by starting up a server; you need to actually have
your key shipped with the Tor source, and have the other directory
authorities agree that you are a directory authority.)  Periodically,
they send each other signed statements of who they believe is in the
network, and they use this collection of signed statements to compute
a "consensus" vote outcome including the results of everybody's vote.
The then all sign the consensus document.

The consensus document includes, for each node that the vote
computation, a digest of that node's long-term "identity" signing key,
and a digest of a "microdescriptor" for that node.  The
microdescriptor is a small unsigned document that contains the node's
medium term "onion key".

Directory caches download these signed consensus documents from the
authorities, and clients download them from caches.  No cache or
client trusts a consensus unless it is signed by greater than half of
the authorities that that cache or client believes in.

So, the trust property is that an attacker cannot dictate the contents
of the consensus unless he controls more than half of the authorities.

Similarly, caches download microdescriptors from the authorities, and
clients download them from caches.  These microdescriptors are *not*
self-authenticating.  You need to make sure that you only use a
microdescriptor for given a node if, when you compute that
microdescriptor's digest, you find that its digest  matches the digest
listed in the consensus networkstatus document.

The person who talked to me on twitter last night seems to be sure
that we do not adequately check whether microdescriptors match their
hashes in the consensus when we download them.  I think he was
confused by looking only at the checking necessary for those
microdescriptors added to the microdesc_map data structure, when in
reality (as I tried to explain in my earlier long email) the critical
step that determines whether a microdesc (and the key it contains)
will be used is when it gets associated with a node_t.  That's the
point when Tor explicitly checks whether the microdescriptor's digest
matches the microdescriptor digest listed for the node of the given ID
in the networkstatus consensus.


(If you think I'm full of shit here, and you want to avoid the whole
microdescriptor system, you can turn it off with "UseMicrodescriptors
0".  I'm sure not perfect.  But on the whole, I'm pretty confident
that the code here actually works like how I'm saying it does.)



best wishes,
-- 
Nick
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk