3

My question is going to be a bit amateurish (bear with me please) but I have read a fair bit of this:

https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt [1]

And it didn't answer it. My understanding may be a bit lacking though.

According to the spec, clients without the consensus document will try to fetch it from "fallback servers" and "authority servers" and when they manage that, later they will try to download it from "directory caches", which are, from my understanding, just nodes that decided to enable that capability and that were voted as such by the autority servers. After the clients have downloaded the consensus document, they will try to "download server descriptors that they are missing". Descriptors are decided as "downloadable" if they are included in the consensus and the "old" descriptors are apparently kept for some time regardless of whether they are included into the consensus document or not. However, it is unclear to me whether the clients check the validity of the consensus. The spec is not perfectly clear about this, but let's assume they do because if they don't, it's a disaster because any rogue directory cache could serve some arbitrary data to some clients and clients couldn't do anything about it. It's not clear to me how clients check the validity of the consensus document, but according to [1], the authority servers publish "detached signatures" that could be verified if clients have public keys for them built in. Let's assume that's the case or some other sane protection mechanism is in place. Then, according to the spec, the clients "SHOULD NOT use unlisted relays", so a well-behaving client will use the most recent consensus document that was served to it from an authority server, a fallback server or a directory cache AND it will use the relays listed in it.

Let's consider a service trustless if we don't have to trust people running the service. Let's restrict the amount of "people running the service" to the people behind Tor development and operation of Tor directory authority servers and "fallback servers" as stated in [1].

Now let's consider the following situation. Due to bribes, blackmail, threats or other circumstances administrators of Tor directory authority servers and fallback servers start collaborating with an adversary. The adversary also runs some amount of directory cache nodes enough so that all people hit one of them say with 20% probability. The goal of the adversary is to target by total surveillance certain IPs with the following attack, combined with other methods to determine some "interesting IPs". The attack is as such: Authority/fallback server software gets modified in a way that it feeds fake consensus documents (with real signatures) to compromised directory caches and targeted clients while behaving in a regular, honest way to the rest of Tor network. Likewise, compromised directory caches feed those fake consensus documents to targeted clients while behaving well for the rest of the network. Naturally, the adversary has also some regular nodes from which the fake consensus is made that don't even need to have their software modified at this point - they are just used for sniffing. Or maybe they could, creating a completely separated Tor network guided by rogue authorities, not that anybody could tell. Finally, the targeted IPs will get completely tracked and sniffed for an arbitrary short period of time or indefinitely.

The attack described is devastating. The attack is hard to detect because only certain IPs could be targeted by that. The attack doesn't need all authorities to succeed, only the majority of them. The attack is virtually undetectable also by the targeted client if the hostile nodes are as well regular Tor nodes (Sybils). Probably hidden services are not as affected by this as they have end-to-end encrypted connection with a help of an .onion service public key but connecting to the hidden service wouldn't reveal the adversary's plot. I find this attack improbable, but realistic.

So, the question I want to ask, assuming I didn't make a mistake in understanding how Tor works: Can we make a point of Tor being trustless or do we have to trust a certain very defined group to use Tor reliably (we don't even assume backdoors in the client software because this we can check at least)? And in the end, can Tor be strengthened even more so we don't have to care? It looks like the "trust bottleneck" in a form of "Tor project people" is still there, though a lot of problems from the past have been mitigated.

  • I believe the “tor project people” are your only worries. Even if something is open source it doesnt mean that vulnerabilities are identified let alone disclosed to the maintainers. Remember heartbleed? – Birb Dec 20 '19 at 21:18
0

You are on par with the thoughts I've had regarding this. And another vector of attack is also possible, but very hard to succeed with storing unique data bound to unique users, somewhere along the road you will find some collision of data, which can then be bound even further. Effectively de-anonymize any user, eventually, thru time.

Just think of how easy that would be on a IRC-network using VHOSTs or some masking of either whole and/or part of the IP/hostname for every user - that just means one thing and one thing only: "Oh! Another piece of information that can be used to fingerprint a user with higher probability" (!!!).

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.