Opened 6 years ago

Closed 6 years ago

#10722 closed defect (fixed)

Wanted to contact directory mirror XXX ... but but it's in our ExcludedNodes list and StrictNodes is set.

Reported by: mr-4 Owned by:
Priority: Medium Milestone: Tor: 0.2.5.x-final
Component: Core Tor/Tor Version: Tor: 0.2.4.19
Severity: Keywords: tor-client tor-hs 024-backport
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When I try to use tor hidden service, most often than not I get the following message:

"[warn] {DIR} Wanted to contact directory mirror XXX at xx.xx.xx.xx for hidden-service v2 descriptor fetch, but it's in our ExcludedNodes list and StrictNodes is set. Skipping. This choice might make your Tor not work."

There is so much wrong in this, I don't know where to start!

  1. Provided I have both EntryNodes, ExcludedNodes and StrictNodes all set, why is tor attempting to connect to a directory mirror it knows is in the ExcludedNodes list and then starts moaning?

This is like banging your head against the wall and then start complaining that it hurts!

The appropriate course of action should have been for tor to try and connect to a directory mirror which is NOT in my ExcludedNodes list.

  1. This whole issue stems from the fact that tor seems to ignore any of my [Alternate]DirAuthority settings as well and does what he wants - please refer to #10461 for details where I provided a detailed bug report, but nobody from the tor devs seems to care.

I also posted about this problem on the tor-talk ML but had nothing but a wall of silence there as well.

As it stands, I can't effectively use ANY tor hidden services as tor tries (and often fails) to get its v2 descriptors and everything goes pair shaped.

Child Tickets

Attachments (1)

tor-10722-alternativehsdir.zip (4.1 KB) - added by mr-4 6 years ago.
AlternativeHSDir log and configuration files

Download all attachments as: .zip

Change History (17)

comment:1 Changed 6 years ago by nickm

Keywords: tor-client tor-hs 024-backport added
Milestone: Tor: 0.2.5.x-final
Status: newneeds_review

It looks like the right solution here is to add an ExcludeNodes check earlier, in directory_get_from_hs_dir().

For review: branch "bug10722" in my public repository. Marking as backportable.

(Re 2: {Alternative}DirAuthority has nothing to do with hidden service directories. The HSDir directory system uses a hash ring to decide where to store the hidden service descriptors for each hidden service; the directory authorities don't enter into it.)

comment:2 in reply to:  1 Changed 6 years ago by mr-4

Replying to nickm:

It looks like the right solution here is to add an ExcludeNodes check earlier, in directory_get_from_hs_dir().

Seems reasonable.

For review: branch "bug10722" in my public repository. Marking as backportable.

I'll pull this and test it if not later today, then tomorrow.

(Re 2: {Alternative}DirAuthority has nothing to do with hidden service directories. The HSDir directory system uses a hash ring to decide where to store the hidden service descriptors for each hidden service; the directory authorities don't enter into it.)

Is there any reason why #10461 isn't looked at?

Also, if I understand you correctly, then using AlternateHSAuthority should fix the problem, at least temporarily, even without your patch applied - provided AlternateHSAuthority works as advertised and I don't get myself in the same situation as with AlternateDirAuthority where tor completely ignores this option and does what it likes (which is what #10461 really is all about).

comment:3 Changed 6 years ago by mr-4

The patch from branch "bug10722" fixes this and works like a charm though I haven't tested it with AlternateHSAuthority - something I'll do when I have more time, probably in the next couple of days.

comment:4 Changed 6 years ago by mr-4

Further to my previous comment, even though the above patch works, if I use AlternativeHSDir statement, that is completely ignored by tor (similar to what I just posted for bug #10461).

I am attaching my log and configuration files.

Changed 6 years ago by mr-4

AlternativeHSDir log and configuration files

comment:5 in reply to:  1 Changed 6 years ago by karsten

Replying to nickm:

It looks like the right solution here is to add an ExcludeNodes check earlier, in directory_get_from_hs_dir().

For review: branch "bug10722" in my public repository. Marking as backportable.

Your branch bug10722, commit bb21d14 looks good to me.

comment:6 Changed 6 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.4.x-final

Merged to master; marking for possible backport to 0.2.4.

comment:7 Changed 6 years ago by arma

So now Tors with too many excludednodes (and notice-level logs) will silently fail to reach some hidden services, where before they got yelled at in their logs?

In the interest of keeping down future bug reports, it might be wise to resume telling them that it's because of excludenodes and strictnodes that their tor is confusingly broken.

comment:8 Changed 6 years ago by nickm

Hm. Maybe we should bump that info warning up to a warn? If so we'll need different text there.

comment:9 Changed 6 years ago by mr-4

Will there be a fix on the AlternativeHSDir not working?

comment:10 in reply to:  8 Changed 6 years ago by nickm

Replying to nickm:

Hm. Maybe we should bump that info warning up to a warn? If so we'll need different text there.

I've added such text to my bug10722 branch and merged it to 0.2.5. It'll go into 0.2.4 as well when/if we merge this branch there.

comment:11 in reply to:  9 Changed 6 years ago by nickm

Replying to mr-4:

Will there be a fix on the AlternativeHSDir not working?

No. I'll try to expand on my explanation above.

AlternativeHSDir (and the very notion of an "hidden service authority") were a part of the version 0 hidden service directory design. In the very first version of hidden services, hidden service descriptors were stored on each of three "hidden service authorities".

Obviously, that's not such a great idea. It doesn't scale, and it gives the authorities too much ability to censor, enumerate, or measure the usage of hidden services.

So in later versions of the hidden service directory system, we got rid of the whole idea of hidden service authorities. Instead, hidden service desciptors are stored at a deterministically chosen, regularly changing set of Tor nodes, chosen from among nodes with the HSDir flag. These "HSDir" nodes are not authorities.

This "version 2 hidden service directory" protocol has been supported partially since 0.2.0 and completely since 0.2.1. Since 0.2.2, no other hidden service directory protocol has been used. In #10841 and #10881, we dropped support for the unused-since-0.2.1 old protocol, since nobody's using it any more.

Okay, so that's why AlternativeHSDir has no meaning with Tor 0.2.2 and later. Note that with the current, "version 2" hidden service directory design, there's no comparable notion of specifying a single server to fetch hidden service descriptors from, because no single server *has* all of the hidden service descriptors: each hidden service uploads to a different subset of hidden service directories (that is, Tor nodes with the HSDir) all the time.

I hope that made sense?

comment:12 Changed 6 years ago by mr-4

Yeah, it does, thanks Nick. Maybe that option should be deprecated, or, at the very least, some sort of warning should be given describing, very briefly, what you've just explained above, otherwise what's the point in keeping an option which does nothing - it is misleading to say the least and I might not be the only one falling for it.

I take it the story with AlternateDirServer option (#10461) is a bit different as that information is available from known/centralised/default directory servers.

comment:13 in reply to:  12 Changed 6 years ago by nickm

Replying to mr-4:

Yeah, it does, thanks Nick. Maybe that option should be deprecated, or, at the very least, some sort of warning should be given describing, very briefly, what you've just explained above, otherwise what's the point in keeping an option which does nothing - it is misleading to say the least and I might not be the only one falling for it.

Right; that's what #10881 was about.

I take it the story with AlternateDirServer option (#10461) is a bit different as that information is available from known/centralised/default directory servers.

Right. (That option *is* a real option.)

comment:14 Changed 6 years ago by nickm

Recommendation: no backport. Nothing actually breaks in this case; there is just a crappy warning. It's also not an 0.2.4 bug; it's been there since 0.2.0

comment:15 Changed 6 years ago by arma

agree, no backport

comment:16 Changed 6 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final
Resolution: fixed
Status: needs_reviewclosed

Okay; closing this one as fixed in 0.2.5.[23]-alpha.

Note: See TracTickets for help on using tickets.