After reading how hidden services work it is not clear to me whether a hidden service database as shown in the figure bellow, is different from a directory server.
On which port does it provide the descriptors on?
2 Answers
The "database" in the picture is an abstraction, it just represents some shared lookup mechanism.
Relays with certain properties can be assigned the HSDir flag.
Bob chooses 6 of these relays in the consensus as the HSDirs to publish his hidden service descriptor to. The 6 chosen are based on his hidden services address and the list of HSDirs in the current consensus.
Alice also knows Bob's hidden service address, this is a shared value that is distributed out-of-band. Since Alice has the same consensus as Bob and Alice knows Bob's hidden service address, she too can compute the same 6 HSDirs and retrieve the descriptor with the information of how to reach Bob's onion from one of them.
They are published and retrieved using Tor's directory protocol which uses HTTP as a transport.
So, in conclusion:
- An
HSDiris a type of Directory Server that meets a specific set of criteria. - There is no single port over which they are served.
Directory server enumerates Tor nodes, all of them. There are special separate subsets of them such as bridge relay directory, obfuscated bridge relay directory, hidden services directory e.t.c. all the records of these special service directories are tor nodes pulled out only by request. The overall directories are used for regular network connectivity rather than by request
- If there are subsets of nodes then it is also possible that a node fulfills more than one role (belongs to more subsets). I don't understand how the hidden service database node works (receives and sends (by request) hidden service descriptors, on which port it runs on, what protocol does it use and more importantly how does a node get picked as a DB node).Sebi– Sebi2015-12-27 09:16:49 +00:00Commented Dec 27, 2015 at 9:16
- @Sebi You are correct : a node can be(and - IMHO - should be) a multi-purpose one. The most common and useful combination is Node+Bridge+OBFS, and - Exit Node + Bridge+OBFS. It runs on a Tor protocol, not on a dedicated port, it's functionality is encapsulated. A nodes are picked on many criterias, but as far as I've noticed it's mainly based on Stability FIRST + consensus weight.2015-12-27 17:27:29 +00:00Commented Dec 27, 2015 at 17:27
- I found out how bandwidth is measured; it is simply being polled each second and stored into two variables related to a connection. The event handler is in main.c. I still have to figure out if the bandwidth authorities do something more specific (i.e. send predefined files and measure transport time).Sebi– Sebi2015-12-27 19:12:49 +00:00Commented Dec 27, 2015 at 19:12
- @Sebi yes, the bandwidth is the main factor in calculating "consensus weight", that is supposed to be the main criteria, BUT - there's my case : in Atlas my weight was decreased due to temporary b/w decrease, I've done it intentionally in an experimentation purposes. But when I've received "Stable" flag for node - it was a big middle probability increase(you can see it also in Atlas for your node). And also in the docs it is said, that b/w will be not the only factor for consensus weights calculation soon, it seems to be true2015-12-27 19:24:49 +00:00Commented Dec 27, 2015 at 19:24