ExitNodes setting sometimes ignored for user traffic

If I set ExitNodes to a country digraph (e.g. {fr}) then most of the circuits delivering my traffic exit via the specified country (these are normal 3 hop circuits).

I also see circuits with 4 hops where the third hop will be in my chosen country but the fourth hop will not. I presume these circuits are being used as described in the man page as they seem to appear after a DIR_FETCH. However, once the circuit has been created it is then used to deliver my traffic for aprroximately the next 10 minutes even though the circuit is exiting via a node in the "wrong" country.

Trac:
Username: a702599

changed milestone to %Tor: 0.2.2.x-final

added ExitNodes component::core tor/tor milestone::Tor: 0.2.2.x-final priority::high reporter::a702599 resolution::fixed status::closed tor-client type::defect version::tor 0.2.2.35 labels

Looks bad. Can anybody reproduce this?

What steps are you taking to find out that it's "used to deliver your traffic"?

Trac:
Priority: normal to major
Milestone: N/A to Tor: 0.2.2.x-final

Also, are you using (or offering) hidden services at the same time?

I have seen this behavior when monitoring circuit and stream events from the control port.

I see normal 3 hop circuits with user traffic. Then I get 4 hop circuits used for DIR_FETCH and these continue being used for user circuits for about ten minutes. Using various online sites I have confirmed that my exit ip is in the "wrong" country when this is happening.

I am not offering any hidden services, but I have seen this happen following a DIR_FETCH when using hidden services (this may also happen if I don't use hidden services but I am unsure).

Do you see the same behavior if you try 0.2.3.x? I think that the stream isolation code there should prevent it entirely. If not, something screwy is going on.

I'll try to track it down in 0.2.2.x.

So, my first shot at this in 0.2.2, if it's an 0.2.2-only issue, would be to add a new circuit purpose for handling anonymized directory connections, since the purpose isolation code seems to work pretty well there. I've got a tentative patch there in branch "bug5283_022_v1" in my public git repository. You can try the patch here:

https://gitweb.torproject.org/nickm/tor.git/patch/41079e070028b6b73a490dd23c565cedf7921f0a?hp=436654ee9670aed5f21f571f3eae743c109a2eba

Warning: it is totally unreviewed by anybody but me, and I've only given it a few minutes of testing. It might or might not work at all, crash horribly, etc.

Trac:
Cc: N/A to arma
Status: new to needs_review

(added arma to the cc list because I'd like a second opinion on the code here.)

There's a simpler fix taking a different approach in branch "bug5283_022_v2" (suggested by rransom). It makes these connections require an "internal" circuit, which is probably right.

One issue there is that the expression "(internal == circ->build_state->is_internal)" in circuit_find_to_cannibalize will probably prevent cannibalization.

Replying to nickm:

There's a simpler fix taking a different approach in branch "bug5283_022_v2" (suggested by rransom). It makes these connections require an "internal" circuit, which is probably right.

I like this one better. I added a changes file in my bug5283_022_v2 branch.

One issue there is that the expression "(internal == circ->build_state->is_internal)" in circuit_find_to_cannibalize will probably prevent cannibalization.

It should allow cannibalization -- but now you'd cannibalize 3-hop internal circuits for fulfilling begin_dir requests, rather than 3-hop non-internal circuits. Right?

Right.

a702599/"cypherpunks", is this something you can test?

Weasel says this is in his opinion potentially mergeable into 0.2.2.x, but it took me a while to explain it to him, so I'm going to improve the commit msg before I merge it.

bug5283_022_v2_described has a better initial commit message, is rebased, and otherwise does not vary from arma's bug5283_022_v2 branch.

I've merged it into maint-0.2.2.

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

Trac:
Keywords: ExitNodes deleted, ExitNodes tor-client added

Trac:
Component: Tor Client to Tor

closed

mentioned in issue #5898 (moved)

moved to tpo/core/tor#5283 (closed)

mentioned in issue tpo/core/tor#5898 (closed)