Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#5283 closed defect (fixed)

ExitNodes setting sometimes ignored for user traffic

Reported by: a702599 Owned by:
Priority: High Milestone: Tor: 0.2.2.x-final
Component: Core Tor/Tor Version: Tor: 0.2.2.35
Severity: Keywords: ExitNodes tor-client
Cc: arma Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (13)

comment:1 Changed 6 years ago by nickm

Milestone: Tor: 0.2.2.x-final
Priority: normalmajor

Looks bad. Can anybody reproduce this?

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

comment:2 Changed 6 years ago by arma

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

comment:3 Changed 6 years ago by cypherpunks

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).

comment:4 Changed 6 years ago by nickm

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.

comment:5 Changed 6 years ago by nickm

Cc: arma added
Status: newneeds_review

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.

comment:6 Changed 6 years ago by nickm

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

comment:7 Changed 6 years ago by 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.

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

comment:8 in reply to:  7 Changed 6 years ago by arma

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?

comment:9 Changed 6 years ago by nickm

Right.

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

comment:10 Changed 6 years ago by nickm

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.

comment:11 Changed 6 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

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.

comment:12 Changed 6 years ago by nickm

Keywords: tor-client added

comment:13 Changed 6 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.