Re: [tor-dev] Questions pertaining to client to directory authority

[Jon Smithe <jonmsmithe@xxxxxxxxx>]

Hello,

I receive a daily digest, so I am replying to everything at once.
> http, https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt
>
> section 1 line 184 "All directory information is uploaded and
> downloaded with HTTP."
>
> If you search through the document for http, you will find most of the
> uris and related info youre looking for.

Well look at that, thank you. That's what I get for skimming a bit too much.


> From: Roger Dingledine <arma@xxxxxxx>
> To: tor-dev@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-dev] Questions pertaining to client to directory
>         authority communications
> Message-ID: <20130519212036.GK31806@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=us-ascii
[...]
> Yeah -- I'm afraid there's a lot to learn at this point. Perhaps when
> you figure out the bootstrapping process to your satisfaction, you'll
> write up a summary and then we can correct it as needed and have a better
> answer for the next person?

As pointed out above, I missed some things while reading the
specifications, I hadn't quite made it to the bottom of the 3rd
version of the directory spec, which is where all the URIs are and is
largely what I was looking for. Piecing together all of the URIs and
their exact contexts through the code was proving to be daunting,
although surprisingly I got most of what I was looking for correctly.
Either way, assuming I feel like I understand things well enough to
explain them at some point, I would think at least throwing together
some type of flow diagram would be fairly painless and I imagine
others would indeed benefit from it.

For anyone reading this in the interim, I actually found starting with
the v1 specification and working towards the v3 was beneficial. I
imagine a lot is outdated, but it somehow managed to make me take note
of other things I had missed in the v3 spec.


> Each directory authority actually has two ports baked into Tor. E.g.,
>     "moria1 orport=9101 no-v2 "
>       "v3ident=D586D18309DED4CD6D57C18FDB97EFA96D330566 "
>       "128.31.0.39:9131 9695 DFC3 5FFE B861 329B 9F1A B04C 4639 7020 CE31",
>
> has 9131 as its DirPort (answering naked http requests), and 9101 as
> its ORPort (doing the Tor TLS handshake). Note that clients by default
> connect to the ORPort and then tunnel their http request through it
> (see the 'begindir' relay cell command), both for authentication and to
> prevent simple DPI-based blocking.

Aha, so I imagine with moria1 the issue is that I'm connecting
directly to port 9131 instead of tunneling it through the ORPort. I
just retested to make sure I hadn't lost my mind and indeed directly
connecting to port 9131 eventually just returns a single byte ('\0').
This seems to be the case with turtles as well, however the other
authorities that serve the dirport over the traditional HTTP port (80)
seem to not have this authentication/DPI evasion behavior.


> That's for asking v2 directory questions, not v3.
>
> We disabled it because of
> https://trac.torproject.org/projects/tor/ticket/6783

I suspected that might be the case. Thanks for the answer.

> Building what basically amounts to a botnet of old Tors, all clamoring
> for obsolete directory information, has certainly proved a learning
> experience. :)

I can imagine you've had a few headaches over the lifetime of the project :)

> Try the v3 protocol, not the v2 protocol.
>
> I just made
> https://trac.torproject.org/projects/tor/ticket/8913
>
> > (tor26 does have the no-v2 flag set which might be the issue?)
>
> (Hm? No it doesn't.)

Indeed you are correct, I must have gotten the lines crossed while
reading them somewhere and mixed it up with another of the
authorities. Either way, despite my criss-cross, my hinting suspicion
was correct: trying to speak v2 to v3 servers (off-hand I'm not
positive which authority I was connected to when I tested/wrote that)


> I think the specs do a pretty good job of explaining what is supported,
> but as you say they don't specify how you should use the protocol.
>
> Some of that is in path-spec.txt.

Indeed, I spoke too soon

> But see also https://trac.torproject.org/projects/tor/ticket/7106

I will be mindful of this as I progress, it's quite evident by all of
the various measurements tor takes that there is a lot of care in the
behavior of the various components.
.

> > I have other questions about aspects of the protocol, but I will  mostly
> > save those until I understand the basic blocks of it better. But to
> > exemplify somewhat, it does seem that the introduction of guard nodes would
> > cause an inverse of desired effect; there appears to be about 1000-1100
> > guard nodes versus a several thousand relays, and about 800-900 exit nodes
> > so it would seem that mitigating the attack where an attacker controlled C
> > number of nodes is essentially pointless as one would only need to control
> > a set number of guard and exit nodes and can more or less ignore the relays
> > in between, so whereas you needed say C/N nodes previously, one would only
> > need Cg/Ng (Cg controlled guards / Ng Number of guards).
>
> It seems you're leaving out Ce/Ne, and/or assuming that the adversary
> controls/observes the destination also.

Well I was more assuming that any adversary that could inject enough
guard nodes would also be able to inject 'enough' exit nodes, as my
understanding is that this is an actual flag they control directly.

> I agree that the guard notion is counterintuitive, and also it's not
> perfect, but I think it's way better than not doing it.

I've not had a chance to read the links you provided, so I am still
speaking from my relatively feeble comprehension, but essentially it
seems like the guards more or less condense the number of entry points
to the network? Whereas there are thousands of potential relays that
could be used as an entry point, there is about a thousand guard
nodes. So, and again I am probably not entirely comprehending
something, but it seems that we've just made the requisite value for C
smaller? (Again assuming that anyone who could get a large volume of
relays of any kind could reasonably also control a large volume of
exit nodes)


> You might like http://freehaven.net/anonbib/#ccs07-doa
> (though it doesn't come with analysis of the guard design, and there's
> still some debate about how the guard design changes things).
> You might also like Mike Perry's work on Path Bias detection. See
> https://trac.torproject.org/projects/tor/ticket/5458 and also look
> in the changelog for the string "Bias".

Will do, thanks!

> 1 guard is better than 3 guards in this respect. But both 1 and 3 are
> way better than 0.

While I agree with this notion, I guess what I am asking is: 'are 3
guard nodes better than X generic entry nodes for values of X that are
significantly larger than 3' (pure example. obviously there is more
than 3 guard nodes). As I'm understanding things, the concept was
introduced to combat the problem discussed in path-spec.txt section 5
(C/N^2), but it seems like the introduction of guard nodes, because
there are so much fewer of them than regular relays and because they
are guaranteed to be an entry point into the network in essence just
makes the value of N smaller and thus the number of C required to
mount at least half of the attack smaller. More over it also removes
the 'guess work' as intermediate relays between the guard and exit
more or less become irrelevant? Rephrased, does converting the problem
to C/N instead of C/N^2 still hold true if in the process we make the
values of N and thus C significantly smaller, at what point does C/N^2
present a better probability?

I'll read more, I am obviously missing something. Thanks a lot for the
links and information.

Jon
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev