#21075 closed enhancement (wontfix)

Tor should listen to the old consensus as long as it helps download fresh one

Reported by: anonymous35654 Owned by:
Priority: Medium Milestone:
Component: Core Tor/Tor Version:
Severity: Major Keywords: dircache, consensus
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Core of the problem is that without any good (fresh, valid or existing) consensus tor daemon attempts to fetch fresh one from main dir authorities (maatuska\gabelmoo\dizum\etc), that are blocked in my case.
However when it has a valid and working consensus, it can successfully download it from guard nodes\other nodes.
In cases like this it is usually recommended to get obfs bridge and get on with it, it does the job for the most people, however it is not an option for me.

But if this would be implemented, tor potentially will be more resilient and resistant to blockings, since (unless tcp packets that are coming from tor could be identified?) ISPs would have to cut off connections to all public tor nodes to block it. And since measures like these would block not only tor, they would have some consequences nobody will like.

I've already tried to place my usual guard nodes into FallbackDir option, but seems that it does something else. In the meantime i did place a public proxy into HTTPProxy option, but that is really a "dirty hack".

If this feature (to allow tor to use old consensus) won't make it into mainstream default tor, i wish it would at least exist as an option for torrc. I would use it.

Child Tickets

Change History (1)

comment:1 in reply to:  description Changed 10 months ago by teor

Resolution: wontfix
Status: newclosed

Replying to anonymous35654:

Core of the problem is that without any good (fresh, valid or existing) consensus tor daemon attempts to fetch fresh one from main dir authorities (maatuska\gabelmoo\dizum\etc), that are blocked in my case.

You are using an older tor client, please upgrade to tor 0.2.8 or later, which implements a "fallback directory mirror" feature that solves this problem by hard-coding a list of stable directory mirrors:

https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors

However when it has a valid and working consensus, it can successfully download it from guard nodes\other nodes.

Tor does this for 24 hours, beyond that the risk of using a malicious directory guard (or being forced to use outdated information) is considered too great. See networkstatus_consensus_reasonably_live().

In cases like this it is usually recommended to get obfs bridge and get on with it, it does the job for the most people, however it is not an option for me.

We actually recommend getting tor 0.2.8 rather than a bridge, it is faster, and will work in most cases.

...

I've already tried to place my usual guard nodes into FallbackDir option, but seems that it does something else. In the meantime i did place a public proxy into HTTPProxy option, but that is really a "dirty hack".

In older Tor versions, the FallbackDir option had some bugs. It was rarely used in those versions, and might not work. In Tor 0.2.8, every client uses the FallbackDir option, so we know it works well.

If this feature (to allow tor to use old consensus) won't make it into mainstream default tor, i wish it would at least exist as an option for torrc. I would use it.

Using older consensuses would make your client stand out. That's why there is no option for this.

Note: See TracTickets for help on using tickets.