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@mit.edu> To: tor-dev@lists.torproject.org Subject: Re: [tor-dev] Questions pertaining to client to directory authority communications Message-ID: <20130519212036.GK31806@moria.seul.org> 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