Warning about using an excluded node for exit
Quite a few people have reported warnings in their logs when using Exclude*Nodes in their torrc. We should track down why this happens, and fix.
I opened the bug so we can keep track of ideas/problem reports. A typical log line would be [Warning] Requested exit node '..' is in ExcludeNodes or ExcludeExitNodes.. Using anyway.
[Automatically added by flyspray2trac: Operating System: All]
Activity
changed milestone to %Tor: 0.2.2.x-final
Patch by rotor to be found at git://git.torproject.org/~sebastian/git/tor branch bug1090
also [rotor] http://pastebin.com/d51430358 related to 1090 with fixed and hided warn only. (note minor patch corruption due to pastebin madness)
[rotator] actualy fix do not fixes anything for 1090, but it prevent a real use excluded nodes if it can happen.
Next patch pushed.
--- circuitbuild.c Fri Jun 19 06:13:52 2009 +++ circuitbuild.c.fix Fri Sep 11 10:18:32 2009 @@ -1436,13 +1436,15 @@ /** Log a warning if the user specified an exit for the circuit that * has been excluded from use by ExcludeNodes or ExcludeExitNodes. */ static void -warn_if_last_router_excluded(uint8_t purpose, const extend_info_t *exit) +warn_if_last_router_excluded(origin_circuit_t *circ, const extend_info_t *exit) { or_options_t *options = get_options(); routerset_t *rs = options->ExcludeNodes; const char *description; int severity; int domain = LD_CIRC; + uint8_t purpose = circ->_base.purpose; + int is_internal = circ->build_state->is_internal; switch (purpose) { @@ -1457,7 +1459,10 @@ case CIRCUIT_PURPOSE_C_GENERAL: description = "Requested exit node"; rs = options->_ExcludeExitNodesUnion; - severity = LOG_WARN; + if (is_internal) + severity = LOG_INFO; + else + severity = LOG_WARN; break; case CIRCUIT_PURPOSE_C_INTRODUCING: case CIRCUIT_PURPOSE_C_INTRODUCE_ACK_WAIT: @@ -1521,7 +1526,7 @@ } if (exit) { /* the circuit-builder pre-requested one */ - warn_if_last_router_excluded(circ->_base.purpose, exit); + warn_if_last_router_excluded(circ, exit); log_info(LD_CIRC,"Using requested exit node '%s'", exit->nickname); exit = extend_info_dup(exit); } else { /* we have to decide one */ @@ -1568,6 +1573,7 @@ circuit_extend_to_new_exit(origin_circuit_t *circ, extend_info_t *exit) { int err_reason = 0; + warn_if_last_router_excluded(circ, exit); circuit_append_new_exit(circ, exit); circuit_set_state(TO_CIRCUIT(circ), CIRCUIT_STATE_BUILDING); if ((err_reason = circuit_send_next_onion_skin(circ))<0) {Some more information which I can't parse right now:
[rotor] circuit_find_to_cannibalize() returns one-hop circ. [rotor] actualy most time it is dirty [rotor] but it connection_ap_attach_pending() depends and contain of conn list [rotor] actualy for now it's safe for general circ, and rend too. because onehop non internal for while. [Sebastian] if the internal requirement doesn't make it safe [rotor] but after 1090 if it becames internal so rend is not safe [rotor] client's intro circ I think [rotor] checking for onehop_tunnel just generalize the func ever. [Sebastian] I feel that this is over my head for now [Sebastian] Maybe at some point nick or roger have enough time to look at it [Sebastian] Do you have a better suggestion? [rotor] if onehop circ planed as resource for rebuilds so need fix 1090 another way.
This bug is beginning to do the rounds in various privacy forums and will be in open water soon enough. From what I can gather there are instances where this flaw is serious. It's reported that it's particularly prevalent where users have tried to exclude known bad exits run by authorities, eg jalopy. It's being mooted that as this "bug" has been around for a while, this is an intentional back door left open in tor by the developers!!!
My own experiences are that there is no way to effectively exclude a group of nodes by country and one is resigned to specifying entry and exit nodes as in the old days...
This bug should be elevated to high priority and medium severity as it has the potential to serious undermine tor's user base.
If a patch exists it needs to be provided in a manner that can allow any non technical user to easily implement it. The notes above and url referrals are not at all usable in this respect.
Finally thanks to those tryin to address this.
Trac:
Username: harris
17:55 <@arma> ok. there are two general classes of bugs here, around 1090 17:55 <@arma> the first is that we need to make sure when we're selecting an exit node for a non-internal non-onehop circuit, we don't pick one in excludeexitnodes 17:55 <@arma> i think we do ok at that, but i'm not sure. i would have to check. there are probably some edge cases, like if we've built a circuit and then they setconf excludeexitnodes, where we fail. 17:56 <@arma> the second class of bug is that we have this warn-if-the-last-hop-looks-like-it's-in-excludedexitnodes function, which warns too eagerly and makes users upset. 17:56 <@arma> we're already kind of in bad shape here, because vidalia shows circuits and doesn't distinguish internal from non-internal, so even if we fix this second category of bugs, we'll still have upset users who have no idea that internal circuits exist.
[...] 18:26 <@arma> also, warn_if_last_router_excluded() should stop saying anything about the log-info ones. they are not bugs. not even at log-info. 18:27 <@arma> i think we should fix warn_if_last_router_excluded so 1) it doesn't log if not an exit, 2) it doesn't log if internal or one-hop. 3) it describes the circuit better when it does log. 18:27 <@arma> then we should fix the circuit-is-acceptable logic to check excludeexitnodes and excludenodes and skip the circuit if it's bad. 18:29 <@arma> if (exitrouter && !connection_ap_can_use_exit(conn, exitrouter)) { 18:29 <@arma> /* can't exit from this router */ 18:31 <@arma> we should amend connection_ap_can_use_exit() to say "no thanks" if the user has set excludestuff
Next part pushed, see http://gitweb.torproject.org/?p=tor/sebastian.git;a=commitdiff;h=dc3229313b6d2aaff437c6fc7fa55ead4409e93d
This means that even if someone says "bla.com.node.exit", we won't use that exit and refuse the connection.
-
IMO we should check circuits for suitability again when we are about to build streams through them.
This way we can: a) Be really really sure that we really have not messed up on any circuits that are used for user streams, or detect it for sure if we have. b) Be able to explain why we're using an excluded node (say for a hidden service).
-
And again: can't general circ be internal if last hop predefined. After reuse prebuilt general circ into some other circuit for rendezvous point or intro point that purpose changes from CIRCUIT_PURPOSE_C_GENERAL to other. Do that more generalizing? So why only for broken kludges?
Whole logic of circuit_find_to_cannibalize() and circ's properties seems broken. No need play with kludges and another smartest math stat, while basis is weak and buggy.
Trac:
Username: OTU -
Folks should have a look at arma's strictnodes branch (in git://git.torproject.org/~arma/git/tor .) He's basically rewriting the way {Exclude}{Entry|Exit}Nodes works, and making a StrictNodes option that is willing to stop Tor from working when doing so would use nodes the user said not to.
-
arma, what's the status of your strictnodes branch? Is it mergeable? Should it get reviewed? Is it already merged?
What your the status here?
Trac:
Description: Quite a few people have reported warnings in their logs when using Exclude*Nodes in their torrc. We should track down why this happens, and fix.I opened the bug so we can keep track of ideas/problem reports. A typical log line would be [Warning] Requested exit node '..' is in ExcludeNodes or ExcludeExitNodes.. Using anyway.
[Automatically added by flyspray2trac: Operating System: All]
to
Quite a few people have reported warnings in their logs when using Exclude*Nodes in their torrc. We should track down why this happens, and fix.
I opened the bug so we can keep track of ideas/problem reports. A typical log line would be [Warning] Requested exit node '..' is in ExcludeNodes or ExcludeExitNodes.. Using anyway.
[Automatically added by flyspray2trac: Operating System: All]
Most of my strictnodes branch is merged, but not all of it. I should merge what remains.
Before that, I should look at proposal 170 and see why I thought it disagreed with my original plan, which is:
i think the trajectory i was heading toward was to make tor do the smart thing, which i think is smart and some users will no doubt be shocked at, unless you set strictnodes, in which case tor will do the stupid thing, and will break in ways that some users will be shocked at