- tor-commits - lists.torproject.org

[tor/release-0.2.2] Issues with router_get_by_nickname()
by arma＠torproject.org 25 Feb '11

25 Feb '11

commit 7488fe5a224bf1c40d22769ff3986361d947d6f7 Author: Robert Hogan <robert(a)roberthogan.net> Date: Sun Oct 17 12:27:57 2010 +0100 Issues with router_get_by_nickname() https://trac.torproject.org/projects/tor/ticket/1859 Use router_get_by_digest() instead of router_get_by_hexdigest() in circuit_discard_optional_exit_enclaves() and rend_client_get_random_intro(), per Nick's comments. Using router_get_by_digest() in rend_client_get_random_intro() will break hidden services published by Tor versions pre 0.1.2.18 and 0.2.07-alpha as they only publish by nickname. This is acceptable however as these versions only publish to authority tor26 and don't work for versions in the 0.2.2.x series anyway. --- src/or/connection_edge.c | 2 +- src/or/rendclient.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/or/connection_edge.c b/src/or/connection_edge.c index eba83ba..f72aa94 100644 --- a/src/or/connection_edge.c +++ b/src/or/connection_edge.c @@ -571,7 +571,7 @@ circuit_discard_optional_exit_enclaves(extend_info_t *info) !edge_conn->chosen_exit_retries) continue; r1 = router_get_by_nickname(edge_conn->chosen_exit_name, 0); - r2 = router_get_by_hexdigest(info->identity_digest); + r2 = router_get_by_digest(info->identity_digest); if (!r1 || !r2 || r1 != r2) continue; tor_assert(edge_conn->socks_request); diff --git a/src/or/rendclient.c b/src/or/rendclient.c index 97fb6f0..ca3f213 100644 --- a/src/or/rendclient.c +++ b/src/or/rendclient.c @@ -810,7 +810,7 @@ rend_client_get_random_intro(const rend_data_t *rend_query) intro = smartlist_get(entry->parsed->intro_nodes, i); /* Do we need to look up the router or is the extend info complete? */ if (!intro->extend_info->onion_key) { - router = router_get_by_hexdigest(intro->extend_info->identity_digest); + router = router_get_by_digest(intro->extend_info->identity_digest); if (!router) { log_info(LD_REND, "Unknown router with nickname '%s'; trying another.", intro->extend_info->nickname);

1 0

[tor/release-0.2.2] Issues with router_get_by_nickname() (3)
by arma＠torproject.org 25 Feb '11

25 Feb '11

commit 5cd7953a2112d6ae8702c741d73b8b6a2d0c5251 Author: Robert Hogan <robert(a)roberthogan.net> Date: Sun Oct 17 15:12:25 2010 +0100 Issues with router_get_by_nickname() (3) Add changes file --- changes/bug1859 | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/changes/bug1859 b/changes/bug1859 new file mode 100644 index 0000000..5b139f3 --- /dev/null +++ b/changes/bug1859 @@ -0,0 +1,9 @@ + o Minor bugfixes: + - Bring the logic that gathers routerinfos and assesses the + acceptability of circuits into line. This prevents a Tor OP from getting + locked in a cycle of choosing its local OR as an exit for a path (due to + a .exit request) and then rejecting the circuit because its OR is not + listed yet. Also prevent Tor clients from using an OR running in the same + instance as an exit (due to a .exit request) if the OR does not meet the + same requirements expected of an OR running elsewhere. + Fixes bug 1859; bugfix on 0.2.0-alpha.

1 0

[tor/release-0.2.2] Issues with router_get_by_nickname()
by arma＠torproject.org 25 Feb '11

25 Feb '11

commit e1d86d381714cb4e85f543fab0ca71f13e58767b Author: Robert Hogan <robert(a)roberthogan.net> Date: Thu Sep 30 21:41:20 2010 +0100 Issues with router_get_by_nickname() https://trac.torproject.org/projects/tor/ticket/1859 There are two problems in this bug: 1. When an OP makes a .exit request specifying itself as the exit, and the exit is not yet listed, Tor gets all the routerinfos needed for the circuit but discovers in circuit_is_acceptable() that its own routerinfo is not in the routerdigest list and cannot be used. Tor then gets locked in a cycle of repeating these two steps. When gathering the routerinfos for a circuit, specifically when the exit has been chosen by .exit notation, Tor needs to apply the same rules it uses later on when deciding if it can build a circuit with those routerinfos. 2. A different bug arises in the above situation when the Tor instance's routerinfo *is* listed in the routerlist, it shares its nickname with a number of other Tor nodes, and it does not have 'Named' rights to its nickname. So for example, if (i) there are five nodes named Bob in the network, (ii) I am running one of them but am flagged as 'Unnamed' because someone else claimed the 'Bob' nickname first, and (iii) I run my Tor as both client and exit the following can happen to me: - I go to www.evil.com - I click on a link www.evil.com.bob.exit - My request will exit through my own Tor node rather than the 'Named' node Bob or any of the others. - www.evil.com now knows I am actually browsing from the same computer that is running my 'Bob' node So to solve both issues we need to ensure: - When fulfilling a .exit request we only choose a routerinfo if it exists in the routerlist, even when that routerinfo is ours. - When getting a router by nickname we only return our own router information if it is not going to be used for building a circuit. We ensure this by removing the special treatment afforded our own router in router_get_by_nickname(). This means the function will only return the routerinfo of our own router if it is in the routerlist built from authority info and has a unique nickname or is bound to a non-unique nickname. There are some uses of router_get_by_nickname() where we are looking for the router by name because of a configuration directive, specifically local declaration of NodeFamilies and EntryNodes and other routers' declaration of MyFamily. In these cases it is not at first clear if we need to continue returning our own routerinfo even if our router is not listed and/or has a non-unique nickname with the Unnamed flag. The patch treats each of these cases as follows: Other Routers' Declaration of MyFamily This happens in routerlist_add_family(). If another router declares our router in its family and our router has the Unnamed flag or is not in the routerlist yet, should we take advantage of the fact that we know our own routerinfo to add us in anyway? This patch says 'no, treat our own router just like any other'. This is a safe choice because it ensures our client has the same view of the network as other clients. We also have no good way of knowing if our router is Named or not independently of the authorities, so we have to rely on them in this. Local declaration of NodeFamilies Again, we have no way of knowing if the declaration 'NodeFamilies Bob,Alice,Ringo' refers to our router Bob or the Named router Bob, so we have to defer to the authorities and treat our own router like any other. Local declaration of NodeFamilies Again, same as above. There's also no good reason we would want our client to choose it's own router as an entry guard if it does not meet the requirements expected of any other router on the network. In order to reduce the possibility of error, the patch also replaces two instances where we were using router_get_by_nickname() with calls to router_get_by_hexdigest() where the identity digest of the router is available. --- src/or/connection_edge.c | 2 +- src/or/rendclient.c | 2 +- src/or/routerlist.c | 3 --- 3 files changed, 2 insertions(+), 5 deletions(-) diff --git a/src/or/connection_edge.c b/src/or/connection_edge.c index ded02e9..eba83ba 100644 --- a/src/or/connection_edge.c +++ b/src/or/connection_edge.c @@ -571,7 +571,7 @@ circuit_discard_optional_exit_enclaves(extend_info_t *info) !edge_conn->chosen_exit_retries) continue; r1 = router_get_by_nickname(edge_conn->chosen_exit_name, 0); - r2 = router_get_by_nickname(info->nickname, 0); + r2 = router_get_by_hexdigest(info->identity_digest); if (!r1 || !r2 || r1 != r2) continue; tor_assert(edge_conn->socks_request); diff --git a/src/or/rendclient.c b/src/or/rendclient.c index 7023b7f..97fb6f0 100644 --- a/src/or/rendclient.c +++ b/src/or/rendclient.c @@ -810,7 +810,7 @@ rend_client_get_random_intro(const rend_data_t *rend_query) intro = smartlist_get(entry->parsed->intro_nodes, i); /* Do we need to look up the router or is the extend info complete? */ if (!intro->extend_info->onion_key) { - router = router_get_by_nickname(intro->extend_info->nickname, 0); + router = router_get_by_hexdigest(intro->extend_info->identity_digest); if (!router) { log_info(LD_REND, "Unknown router with nickname '%s'; trying another.", intro->extend_info->nickname); diff --git a/src/or/routerlist.c b/src/or/routerlist.c index 2fc8073..9622406 100644 --- a/src/or/routerlist.c +++ b/src/or/routerlist.c @@ -1989,9 +1989,6 @@ router_get_by_nickname(const char *nickname, int warn_if_unnamed) return router_get_by_hexdigest(nickname); if (!strcasecmp(nickname, UNNAMED_ROUTER_NICKNAME)) return NULL; - if (server_mode(get_options()) && - !strcasecmp(nickname, get_options()->Nickname)) - return router_get_my_routerinfo(); maybedigest = (strlen(nickname) >= HEX_DIGEST_LEN) && (base16_decode(digest,DIGEST_LEN,nickname,HEX_DIGEST_LEN) == 0);

1 0

[tor/release-0.2.2] Fix a remaining bug in Robert's bug1859 fix.
by arma＠torproject.org 25 Feb '11

25 Feb '11

commit 2392290c1887b732fd2309e57ce04ab71b9b4e69 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Oct 21 11:08:15 2010 -0400 Fix a remaining bug in Robert's bug1859 fix. When intro->extend_info is created for an introduction point, it only starts out with a nickname, not necessarily an identity digest. Thus, doing router_get_by_digest isn't necessarily safe. --- src/or/rendclient.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/src/or/rendclient.c b/src/or/rendclient.c index ca3f213..1f253c1 100644 --- a/src/or/rendclient.c +++ b/src/or/rendclient.c @@ -810,7 +810,10 @@ rend_client_get_random_intro(const rend_data_t *rend_query) intro = smartlist_get(entry->parsed->intro_nodes, i); /* Do we need to look up the router or is the extend info complete? */ if (!intro->extend_info->onion_key) { - router = router_get_by_digest(intro->extend_info->identity_digest); + if (tor_digest_is_zero(intro->extend_info->identity_digest)) + router = router_get_by_hexdigest(intro->extend_info->nickname); + else + router = router_get_by_digest(intro->extend_info->identity_digest); if (!router) { log_info(LD_REND, "Unknown router with nickname '%s'; trying another.", intro->extend_info->nickname);

1 0

[tor/release-0.2.2] Turn the loop bodies of rep_hist_save/load_state into functions
by arma＠torproject.org 25 Feb '11

25 Feb '11

commit 8dd4ecd14e6e6e886c76c8464595d4f903447c42 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Jan 10 12:57:44 2011 -0500 Turn the loop bodies of rep_hist_save/load_state into functions The trick of looping from i=0..4 , switching on i to set up some variables, then running some common code is much better expressed by just calling a function 4 times with 4 sets of arguments. This should make the code a little easier to follow and maintain here. --- src/or/rephist.c | 243 +++++++++++++++++++++++++---------------------------- 1 files changed, 115 insertions(+), 128 deletions(-) diff --git a/src/or/rephist.c b/src/or/rephist.c index d85a8b7..c220426 100644 --- a/src/or/rephist.c +++ b/src/or/rephist.c @@ -1392,7 +1392,7 @@ rep_hist_bandwidth_assess(void) * It returns the number of bytes written. */ static size_t -rep_hist_fill_bandwidth_history(char *buf, size_t len, bw_array_t *b) +rep_hist_fill_bandwidth_history(char *buf, size_t len, const bw_array_t *b) { char *cp = buf; int i, n; @@ -1484,161 +1484,148 @@ rep_hist_get_bandwidth_lines(void) return buf; } +/** Write a single bw_warray_t from its Values, Ends, and Interval entries + * from a state. */ +static void +rep_hist_update_bwhist_state_section(or_state_t *state, + const bw_array_t *b, + smartlist_t **s_values, + time_t *s_begins, + int *s_interval) +{ + char buf[20*NUM_TOTALS + 1], *cp; + + if (*s_values) { + SMARTLIST_FOREACH(*s_values, char *, val, tor_free(val)); + smartlist_free(*s_values); + } + if (! server_mode(get_options())) { + /* Clients don't need to store bandwidth history persistently; + * force these values to the defaults. */ + /* FFFF we should pull the default out of config.c's state table, + * so we don't have two defaults. */ + if (*s_begins != 0 || *s_interval != 900) { + time_t now = time(NULL); + time_t save_at = get_options()->AvoidDiskWrites ? now+3600 : now+600; + or_state_mark_dirty(state, save_at); + } + *s_begins = 0; + *s_interval = 900; + *s_values = smartlist_create(); + return; + } + *s_begins = b->next_period; + *s_interval = NUM_SECS_BW_SUM_INTERVAL; + cp = buf; + cp += rep_hist_fill_bandwidth_history(cp, sizeof(buf), b); + tor_snprintf(cp, sizeof(buf)-(cp-buf), + cp == buf ? U64_FORMAT : ","U64_FORMAT, + U64_PRINTF_ARG(b->total_in_period)); + *s_values = smartlist_create(); + if (server_mode(get_options())) + smartlist_split_string(*s_values, buf, ",", SPLIT_SKIP_SPACE, 0); +} + /** Update <b>state</b> with the newest bandwidth history. */ void rep_hist_update_state(or_state_t *state) { - int len, r; - char *buf, *cp; - smartlist_t **s_values = NULL; - time_t *s_begins = NULL; - int *s_interval = NULL; - bw_array_t *b = NULL; +#define UPDATE(arrname,st) \ + rep_hist_update_bwhist_state_section(state,\ + (arrname),\ + &state->BWHistory ## st ## Values, \ + &state->BWHistory ## st ## Ends, \ + &state->BWHistory ## st ## Interval) - len = 20*NUM_TOTALS+1; - buf = tor_malloc_zero(len); + UPDATE(write_array, Write); + UPDATE(read_array, Read); + UPDATE(dir_write_array, DirWrite); + UPDATE(dir_read_array, DirRead); - for (r=0;r<4;++r) { - switch (r) { - case 0: - b = write_array; - s_begins = &state->BWHistoryWriteEnds; - s_interval = &state->BWHistoryWriteInterval; - s_values = &state->BWHistoryWriteValues; - break; - case 1: - b = read_array; - s_begins = &state->BWHistoryReadEnds; - s_interval = &state->BWHistoryReadInterval; - s_values = &state->BWHistoryReadValues; - break; - case 2: - b = dir_write_array; - s_begins = &state->BWHistoryDirWriteEnds; - s_interval = &state->BWHistoryDirWriteInterval; - s_values = &state->BWHistoryDirWriteValues; - break; - case 3: - b = dir_read_array; - s_begins = &state->BWHistoryDirReadEnds; - s_interval = &state->BWHistoryDirReadInterval; - s_values = &state->BWHistoryDirReadValues; - break; - } - if (*s_values) { - SMARTLIST_FOREACH(*s_values, char *, val, tor_free(val)); - smartlist_free(*s_values); - } - if (! server_mode(get_options())) { - /* Clients don't need to store bandwidth history persistently; - * force these values to the defaults. */ - /* FFFF we should pull the default out of config.c's state table, - * so we don't have two defaults. */ - if (*s_begins != 0 || *s_interval != 900) { - time_t now = time(NULL); - time_t save_at = get_options()->AvoidDiskWrites ? now+3600 : now+600; - or_state_mark_dirty(state, save_at); - } - *s_begins = 0; - *s_interval = 900; - *s_values = smartlist_create(); - continue; - } - *s_begins = b->next_period; - *s_interval = NUM_SECS_BW_SUM_INTERVAL; - cp = buf; - cp += rep_hist_fill_bandwidth_history(cp, len, b); - tor_snprintf(cp, len-(cp-buf), cp == buf ? U64_FORMAT : ","U64_FORMAT, - U64_PRINTF_ARG(b->total_in_period)); - *s_values = smartlist_create(); - if (server_mode(get_options())) - smartlist_split_string(*s_values, buf, ",", SPLIT_SKIP_SPACE, 0); - } - tor_free(buf); if (server_mode(get_options())) { - or_state_mark_dirty(get_or_state(), time(NULL)+(2*3600)); + or_state_mark_dirty(state, time(NULL)+(2*3600)); } +#undef UPDATE } -/** Set bandwidth history from our saved state. */ -int -rep_hist_load_state(or_state_t *state, char **err) +/** Load a single bw_warray_t from its Values, Ends, and Interval entries from + * a state. */ +static int +rep_hist_load_bwhist_state_section(bw_array_t *b, + const smartlist_t *s_values, + const time_t s_begins, + const int s_interval) { - time_t s_begins = 0, start; time_t now = time(NULL); - uint64_t v; - int r,i,ok; - int all_ok = 1; - int s_interval = 0; - smartlist_t *s_values = NULL; - bw_array_t *b = NULL; - - /* Assert they already have been malloced */ - tor_assert(read_array && write_array); + int retval = 0; + time_t start; - for (r=0;r<4;++r) { - switch (r) { - case 0: - b = write_array; - s_begins = state->BWHistoryWriteEnds; - s_interval = state->BWHistoryWriteInterval; - s_values = state->BWHistoryWriteValues; - break; - case 1: - b = read_array; - s_begins = state->BWHistoryReadEnds; - s_interval = state->BWHistoryReadInterval; - s_values = state->BWHistoryReadValues; - break; - case 2: - b = dir_write_array; - s_begins = state->BWHistoryDirWriteEnds; - s_interval = state->BWHistoryDirWriteInterval; - s_values = state->BWHistoryDirWriteValues; - break; - case 3: - b = dir_read_array; - s_begins = state->BWHistoryDirReadEnds; - s_interval = state->BWHistoryDirReadInterval; - s_values = state->BWHistoryDirReadValues; - break; - } - if (s_values && s_begins >= now - NUM_SECS_BW_SUM_INTERVAL*NUM_TOTALS) { - start = s_begins - s_interval*(smartlist_len(s_values)); - if (start > now) - continue; - b->cur_obs_time = start; - b->next_period = start + NUM_SECS_BW_SUM_INTERVAL; - SMARTLIST_FOREACH(s_values, char *, cp, { + uint64_t v; + int i,ok; + + if (s_values && s_begins >= now - NUM_SECS_BW_SUM_INTERVAL*NUM_TOTALS) { + start = s_begins - s_interval*(smartlist_len(s_values)); + if (start > now) + return 0; + b->cur_obs_time = start; + b->next_period = start + NUM_SECS_BW_SUM_INTERVAL; + SMARTLIST_FOREACH_BEGIN(s_values, const char *, cp) { v = tor_parse_uint64(cp, 10, 0, UINT64_MAX, &ok, NULL); if (!ok) { - all_ok=0; + retval = -1; log_notice(LD_HIST, "Could not parse '%s' into a number.'", cp); } if (start < now) { add_obs(b, start, v); start += NUM_SECS_BW_SUM_INTERVAL; } - }); - } + } SMARTLIST_FOREACH_END(cp); + } - /* Clean up maxima and observed */ - /* Do we really want to zero this for the purpose of max capacity? */ - for (i=0; i<NUM_SECS_ROLLING_MEASURE; ++i) { - b->obs[i] = 0; - } - b->total_obs = 0; - for (i=0; i<NUM_TOTALS; ++i) { - b->maxima[i] = 0; - } - b->max_total = 0; + /* Clean up maxima and observed */ + /* Do we really want to zero this for the purpose of max capacity? */ + for (i=0; i<NUM_SECS_ROLLING_MEASURE; ++i) { + b->obs[i] = 0; + } + b->total_obs = 0; + for (i=0; i<NUM_TOTALS; ++i) { + b->maxima[i] = 0; } + b->max_total = 0; + + return retval; +} + +/** Set bandwidth history from our saved state. */ +int +rep_hist_load_state(or_state_t *state, char **err) +{ + int all_ok = 1; + /* Assert they already have been malloced */ + tor_assert(read_array && write_array); + tor_assert(dir_read_array && dir_write_array); + +#define LOAD(arrname,st) \ + if (rep_hist_load_bwhist_state_section( \ + (arrname), \ + state->BWHistory ## st ## Values, \ + state->BWHistory ## st ## Ends, \ + state->BWHistory ## st ## Interval)<0) \ + all_ok = 0 + + LOAD(write_array, Write); + LOAD(read_array, Read); + LOAD(dir_write_array, DirWrite); + LOAD(dir_read_array, DirRead); + +#undef LOAD if (!all_ok) { *err = tor_strdup("Parsing of bandwidth history values failed"); /* and create fresh arrays */ tor_free(read_array); tor_free(write_array); + read_array = bw_array_new(); write_array = bw_array_new(); return -1;

1 0

[tor/release-0.2.2] Fix bug when parsing bwhist with unexpected Interval
by arma＠torproject.org 25 Feb '11

25 Feb '11

commit 7e1502c0d1aa0875fba0b26ddcf021bdfa5e11a0 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Jan 10 13:06:50 2011 -0500 Fix bug when parsing bwhist with unexpected Interval Previously, our state parsing code would fail to parse a bwhist correctly if the Interval was anything other than the default hardcoded 15 minutes. This change makes the parsing less incorrect, though the resulting history array might get strange values in it if the intervals don't match the one we're using. (That is, if stuff was generated in 15 minute intervals, and we read it into an array that expects 30 minute intervals, we're fine, since values can be combined pairwise. But if we generate data at 30 minute intervals and read it into 15 minute intervals, alternating buckets will be empty.) Bugfix on 0.1.1.11-alpha. --- changes/1863_bwhist | 5 +++++ src/or/rephist.c | 6 +++++- 2 files changed, 10 insertions(+), 1 deletions(-) diff --git a/changes/1863_bwhist b/changes/1863_bwhist new file mode 100644 index 0000000..c1d4d86 --- /dev/null +++ b/changes/1863_bwhist @@ -0,0 +1,5 @@ + o Minor bugfixes + - Fix a bug in banwidth history state parsing that could have been + triggered if a future version of Tor ever changed the timing + granularity at which bandwidth history is measured. Bugfix on + Tor 0.1.1.11-alpha. diff --git a/src/or/rephist.c b/src/or/rephist.c index c220426..5a3a15e 100644 --- a/src/or/rephist.c +++ b/src/or/rephist.c @@ -1165,6 +1165,8 @@ rep_hist_load_mtbf_data(time_t now) * totals? */ #define NUM_SECS_ROLLING_MEASURE 10 /** How large are the intervals for which we track and report bandwidth use? */ +/* XXXX Watch out! Before Tor 0.2.2.21-alpha, using any other value here would + * generate an unparseable state file. */ #define NUM_SECS_BW_SUM_INTERVAL (15*60) /** How far in the past do we remember and publish bandwidth use? */ #define NUM_SECS_BW_SUM_IS_VALID (24*60*60) @@ -1577,7 +1579,9 @@ rep_hist_load_bwhist_state_section(bw_array_t *b, } if (start < now) { add_obs(b, start, v); - start += NUM_SECS_BW_SUM_INTERVAL; + /* This will result in some fairly choppy history if s_interval + * is notthe same as NUM_SECS_BW_SUM_INTERVAL. XXXX */ + start += s_interval; } } SMARTLIST_FOREACH_END(cp); }

1 0

[torspec/master] cleanup proposals as i read them
by arma＠torproject.org 25 Feb '11

25 Feb '11

commit 13bd8dd35c887487033f2b17831c9adc0e0cbf86 Author: Roger Dingledine <arma(a)torproject.org> Date: Fri Feb 25 13:33:21 2011 -0500 cleanup proposals as i read them --- proposals/168-reduce-circwindow.txt | 2 +- proposals/169-eliminating-renegotiation.txt | 15 ++++---- proposals/173-getinfo-option-expansion.txt | 52 ++++++++++++++------------- proposals/175-automatic-node-promotion.txt | 4 ++- proposals/ideas/xxx-pluggable-transport.txt | 20 ++++++----- 5 files changed, 50 insertions(+), 43 deletions(-) diff --git a/proposals/168-reduce-circwindow.txt b/proposals/168-reduce-circwindow.txt index c10cf41..a746286 100644 --- a/proposals/168-reduce-circwindow.txt +++ b/proposals/168-reduce-circwindow.txt @@ -37,7 +37,7 @@ Target: 0.2.2 The median round-trip latency appears to be around 2s, with 25% of the data points taking more than 5s. That's a lot of variance. - We designed Tor originally with the original goal of maximizing + We designed Tor originally with the goal of maximizing throughput. We figured that would also optimize other network properties like round-trip latency. Looks like we were wrong. diff --git a/proposals/169-eliminating-renegotiation.txt b/proposals/169-eliminating-renegotiation.txt index 2c90f9c..6311124 100644 --- a/proposals/169-eliminating-renegotiation.txt +++ b/proposals/169-eliminating-renegotiation.txt @@ -31,7 +31,7 @@ Target: 0.2.2 In the current Tor TLS connection handshake protocol ("V2", or "renegotiating"), the parties begin with a single certificate sent from the server (responder) to the client (initiator), and - then renegotiate to a two-certs-from-each-authenticating party. + then renegotiate to a two-certs-from-each-authenticating-party. We made this change to make Tor's handshake look like a browser speaking SSL to a webserver. (See proposal 130, and tor-spec.txt.) To tell whether to use the V1 or V2 handshake, @@ -171,7 +171,7 @@ Target: 0.2.2 On learning the link protocol, the server then sends the client a CERT cell and a NETINFO cell. If the client wants to authenticate to the server, it sends a CERT cell, an AUTHENTICATE - cell, and a NETINFO cell, or it may simply send a NETINFO cell if + cell, and a NETINFO cell; or it may simply send a NETINFO cell if it does not want to authenticate. The CERT cell describes the keys that a Tor instance is claiming @@ -199,7 +199,7 @@ Target: 0.2.2 where CertType is 1 (meaning "RSA/SHA256") CertPurpose is 1 (meaning "link certificate") PublicKey is the DER encoding of the ASN.1 representation - of the RSA key of the subject of this certificate, + of the RSA key of the subject of this certificate NotBefore is a time in HOURS since January 1, 1970, 00:00 UTC before which this certificate should not be considered valid. @@ -208,7 +208,7 @@ Target: 0.2.2 considered valid. SignerID is the SHA-256 digest of the public key signing this certificate - and Signature is the signature of the all other fields in + and Signature is the signature of all the other fields in this certificate, using SHA256 as described in proposal 158. @@ -362,12 +362,12 @@ Target: 0.2.2 We need to reserve command numbers for CERT and AUTH cells. I suggest that in link protocol 3 and higher, we reserve command numbers 128..240 for variable-length cells. (241-256 we can hold - for future extensions. + for future extensions.) 5. Efficiency - This protocol add a round-trip step when the client sends a - VERSIONS cell to the server, and waits for the {VERSIONS, CERT, + This protocol adds a round-trip step when the client sends a + VERSIONS cell to the server and waits for the {VERSIONS, CERT, NETINFO} response in turn. (The server then waits for the client's {NETINFO} or {CERT, AUTHENTICATE, NETINFO} reply, but it would have already been waiting for the client's NETINFO, @@ -402,3 +402,4 @@ Target: 0.2.2 - What should servers that don't have TLS renegotiation do? For now, I think they should just get it. Eventually we can deprecate the V2 handshake as we did with the V1 handshake. + diff --git a/proposals/173-getinfo-option-expansion.txt b/proposals/173-getinfo-option-expansion.txt index 03e18ef..54356c9 100644 --- a/proposals/173-getinfo-option-expansion.txt +++ b/proposals/173-getinfo-option-expansion.txt @@ -7,7 +7,7 @@ Status: Accepted Overview: Over the course of developing arm there's been numerous hacks and - workarounds to gleam pieces of basic, desirable information about the tor + workarounds to glean pieces of basic, desirable information about the tor process. As per Roger's request I've compiled a list of these pain points to try and improve the control protocol interface. @@ -15,19 +15,19 @@ Motivation: The purpose of this proposal is to expose additional process and relay related information that is currently unavailable in a convenient, - dependable, and/or platform independent way. Examples of this are... - + dependable, and/or platform independent way. Examples are: + - The relay's total contributed bandwidth. This is a highly requested piece of information and, based on the following patch from pipe, looks trivial to include. http://www.mail-archive.com/or-talk@freehaven.net/msg13085.html - + - The process ID of the tor process. There is a high degree of guess work in obtaining this. Arm for instance uses pidof, netstat, and ps yet still fails on some platforms, and Orbot recently got a ticket about its own attempt to fetch it with ps: https://trac.torproject.org/projects/tor/ticket/1388 - + This just includes the pieces of missing information I've noticed (suggestions or questions of their usefulness are welcome!). @@ -39,43 +39,45 @@ Security Implications: Specification: The following addition would be made to the control-spec's GETINFO section: - + "relay/bw-limit" -- Effective relayed bandwidth limit. - + "relay/burst-limit" -- Effective relayed burst limit. - + "relay/read-total" -- Total bytes relayed (download). - + "relay/write-total" -- Total bytes relayed (upload). - + "relay/flags" -- Space separated listing of flags currently held by the - relay as repored by the currently cached consensus. - + relay as reported by the currently cached consensus. + "process/user" -- Username under which the tor process is running, - providing an empty string if none exists. - + or an empty string if none exists. + [what do we mean 'if none exists'?] + "process/pid" -- Process id belonging to the main tor process, -1 if none exists for the platform. - + "process/uptime" -- Total uptime of the tor process (in seconds). - + "process/uptime-reset" -- Time since last reset (startup, sighup, or RELOAD - signal, in seconds). - + signal, in seconds). [should clarify exactly which events cause an + uptime reset] + "process/descriptors-used" -- Count of file descriptors used. - + "process/descriptor-limit" -- File descriptor limit (getrlimit results). - + "ns/authority" -- Router status info (v2 directory style) for all recognized directory authorities, joined by newlines. - + "state/names" -- A space-separated list of all the keys supported by this version of Tor's state. - + "state/val/<key>" -- Provides the current state value belonging to the given key. If undefined, this provides the key's default value. - - "status/ports-seen" -- A summary of which ports we've seen connections + + "status/ports-seen" -- A summary of which ports we've seen connections' circuits connect to recently, formatted the same as the EXITS_SEEN status event described in Section 4.1.XX. This GETINFO option is currently available only for exit relays. @@ -90,7 +92,7 @@ Specification: in their "relay" configuration window, to give them a sense of how they're being used (popularity of the various ports they exit to). Currently only exit relays will receive this event. - + TimeStarted is a quoted string indicating when the reported summary counts from (in GMT). diff --git a/proposals/175-automatic-node-promotion.txt b/proposals/175-automatic-node-promotion.txt index c990b3f..f97cec0 100644 --- a/proposals/175-automatic-node-promotion.txt +++ b/proposals/175-automatic-node-promotion.txt @@ -175,6 +175,8 @@ Status: Draft might as well be a new one with no history. This policy may change once we start allowing the bridge authority to hand out new IP addresses given the fingerprint. + [Perhaps another consensus param? Also, this means we save previous + IP address in our state file, yes? -RD] 3.x Bandwidth measurement @@ -222,7 +224,7 @@ Status: Draft * Publication of IP address * Blocking from IRC (even for non-exit relays) - - What feedback should we give to bridge relays, to encourage then + - What feedback should we give to bridge relays, to encourage them e.g. number of recent users (what about reserve bridges)? - Can clients back-off from doing these tests (yes, we should do diff --git a/proposals/ideas/xxx-pluggable-transport.txt b/proposals/ideas/xxx-pluggable-transport.txt index 53ba9c6..c23ba92 100644 --- a/proposals/ideas/xxx-pluggable-transport.txt +++ b/proposals/ideas/xxx-pluggable-transport.txt @@ -109,13 +109,13 @@ Design overview To write a new transport protocol, an implementer must provide two pieces: a "Client Proxy" to run at the initiator side, and a "Server - Proxy" to run a the server side. These two pieces may or may not be + Proxy" to run at the server side. These two pieces may or may not be implemented by the same program. Each client may run any number of Client Proxies. Each one acts like - a SOCKS proxy that accepts accept connections on localhost. Each one + a SOCKS proxy that accepts connections on localhost. Each one runs on a different port, and implements one or more transport - methods. If the protocol has any parameters, they passed from Tor + methods. If the protocol has any parameters, they are passed from Tor inside the regular username/password parts of the SOCKS protocol. Bridges (and maybe relays) may run any number of Server Proxies: these @@ -147,7 +147,7 @@ Specifications: Client behavior on the TLS connection to match the digest provided in [id-fingerprint]. If any [k=v] items are provided, they are configuration parameters for the proxy: Tor should separate them with - semicolons and put them user and password fields of the request, + semicolons and put them in the user and password fields of the request, splitting them across the fields as necessary. If a key or value value must contain a semicolon or a backslash, it is escaped with a backslash. @@ -174,6 +174,7 @@ Specifications: Client behavior connections. The Tor client only launches one instance of each external program, even if the same executable is listed for more than one method. + [What if the options are different? -RD] The same program can implement a managed or an external proxy: it just needs to take an argument saying which one to be. @@ -237,8 +238,8 @@ Server proxy behavior [If we're using the bridge authority/bridgedb system for distributing bridge info, the right place to advertise bridge lines is probably - the extrainfo document. We also need a way to tell the bridge - authority "don't give out a default bridge line for me"] + the extrainfo document. We also need a way to tell bridgedb + "don't give out a default bridge line for me"] Server behavior @@ -289,12 +290,12 @@ Appendix: recommendations for transports make it either get a small userbase, or poor auditing. Think secure: if your code is in a C-like language, and it's hard to - read it and become convinced it's safe then, it's probably not safe. + read it and become convinced it's safe, then it's probably not safe. Think small: we want to minimize the bytes that a Windows user needs to download for a transport client. - Specify: if you can't come up with a good explanation + Specify: if you can't come up with a good explanation [XXX] Avoid security-through-obscurity if possible. Specify. @@ -309,4 +310,5 @@ Appendix: recommendations for transports Appendix: Raw-traffic transports This section describes an optional extension to the proposal above. - We are not sure whether it is a good idea. + We are not sure whether it is a good idea. +

1 0

[tor/master] Fix for #1074 "Part 3"
by nickm＠torproject.org 25 Feb '11

25 Feb '11

commit 24096d0cec3084b2cbc1c35cbb26a5d92dd4add2 Author: AltF4 <altf4(a)phx2600.org> Date: Tue Feb 15 22:36:41 2011 -0700 Fix for #1074 "Part 3" Changed received_netinfo_from_trusted_dir into a tristate in order to keep track of whether we have already tried contacting a trusted dir. So we don't send multiple requests if we get a bunch of skews. --- src/or/command.c | 23 ++++++++++++++++------- 1 files changed, 16 insertions(+), 7 deletions(-) diff --git a/src/or/command.c b/src/or/command.c index c873516..44420c9 100644 --- a/src/or/command.c +++ b/src/or/command.c @@ -45,7 +45,11 @@ uint64_t stats_n_versions_cells_processed = 0; /** How many CELL_NETINFO cells have we received, ever? */ uint64_t stats_n_netinfo_cells_processed = 0; /** Have we received a NETINFO cell from a trusted dir, ever? Used - * to decide what to do about time skew. */ + * to decide what to do about time skew. + * 0 == No, and and we haven't tried asking an authority yet + * 1 == No, we've launched a query but haven't heard back yet + * 2 == Yes + **/ static int received_netinfo_from_trusted_dir = 0; /* These are the main functions for processing cells */ @@ -625,9 +629,9 @@ command_process_netinfo_cell(cell_t *cell, or_connection_t *conn) #define NETINFO_NOTICE_SKEW 3600 if (labs(apparent_skew) > NETINFO_NOTICE_SKEW && router_get_by_digest(conn->identity_digest) && - !received_netinfo_from_trusted_dir) { + received_netinfo_from_trusted_dir != 2) { char dbuf[64]; - /*XXXX be smarter about when everybody says we are skewed. */ + int severity = router_digest_is_trusted_dir(conn->identity_digest) ? LOG_WARN : LOG_INFO; format_time_interval(dbuf, sizeof(dbuf), apparent_skew); @@ -643,7 +647,10 @@ command_process_netinfo_cell(cell_t *cell, or_connection_t *conn) "CLOCK_SKEW SKEW=%ld SOURCE=OR:%s:%d", apparent_skew, conn->_base.address, conn->_base.port); - } else { /* Connect to a trusted dir to trigger a NETINFO cell*/ + received_netinfo_from_trusted_dir = 2; + /* Connect to a trusted dir to trigger a NETINFO cell + * only if we haven't already */ + } else if(received_netinfo_from_trusted_dir == 0) { routerstatus_t *any_trusted_dir = router_pick_trusteddirserver(NO_AUTHORITY, 0); tor_addr_t trusted_dir_addr; @@ -651,12 +658,14 @@ command_process_netinfo_cell(cell_t *cell, or_connection_t *conn) connection_or_connect(&trusted_dir_addr, any_trusted_dir->or_port, any_trusted_dir->descriptor_digest); + received_netinfo_from_trusted_dir = 1; } } - /* Note that we received a netinfo cell from a trusted directory */ - if (router_digest_is_trusted_dir(conn->identity_digest)) - received_netinfo_from_trusted_dir = 1; + /* Note that we received a good netinfo cell from a trusted directory */ + if (router_digest_is_trusted_dir(conn->identity_digest) && + labs(apparent_skew) <= NETINFO_NOTICE_SKEW) + received_netinfo_from_trusted_dir = 2; /* XXX maybe act on my_apparent_addr, if the source is sufficiently * trustworthy. */

1 0

[tor/master] Fix for #1074 previous rev
by nickm＠torproject.org 25 Feb '11

25 Feb '11

commit 612c7f32424d31dac51baad22e17ff4faf2b9b43 Author: AltF4 <altf4(a)phx2600.org> Date: Wed Feb 23 21:33:06 2011 -0700 Fix for #1074 previous rev Changed tor_addr_from_ipv4n to tor_addr_from_ipv4h and changed descriptor_digest to identity_digest --- src/or/command.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/or/command.c b/src/or/command.c index 44420c9..ef3a559 100644 --- a/src/or/command.c +++ b/src/or/command.c @@ -654,10 +654,10 @@ command_process_netinfo_cell(cell_t *cell, or_connection_t *conn) routerstatus_t *any_trusted_dir = router_pick_trusteddirserver(NO_AUTHORITY, 0); tor_addr_t trusted_dir_addr; - tor_addr_from_ipv4n(&trusted_dir_addr, any_trusted_dir->addr); + tor_addr_from_ipv4h(&trusted_dir_addr, any_trusted_dir->addr); connection_or_connect(&trusted_dir_addr, any_trusted_dir->or_port, - any_trusted_dir->descriptor_digest); + any_trusted_dir->identity_digest); received_netinfo_from_trusted_dir = 1; } }

1 0

[tor/master] Sebastian's Changes to #1074
by nickm＠torproject.org 25 Feb '11

25 Feb '11

commit 82023f6a1ebb25e48a9ccfd9d68f5ebc5ea8c4c0 Author: AltF4 <altf4(a)phx2600.org> Date: Tue Feb 15 22:32:21 2011 -0700 Sebastian's Changes to #1074 Fixes some small mistakes with AltF4's #1074 fix --- src/or/command.c | 34 ++++++++++++---------------------- 1 files changed, 12 insertions(+), 22 deletions(-) diff --git a/src/or/command.c b/src/or/command.c index abe755e..c873516 100644 --- a/src/or/command.c +++ b/src/or/command.c @@ -44,8 +44,9 @@ uint64_t stats_n_destroy_cells_processed = 0; uint64_t stats_n_versions_cells_processed = 0; /** How many CELL_NETINFO cells have we received, ever? */ uint64_t stats_n_netinfo_cells_processed = 0; -/** Have we received skew info from a NETINFO cell from a trusted dir, ever? */ -static int received_skew_from_trusted_dir = 0; +/** Have we received a NETINFO cell from a trusted dir, ever? Used + * to decide what to do about time skew. */ +static int received_netinfo_from_trusted_dir = 0; /* These are the main functions for processing cells */ static void command_process_create_cell(cell_t *cell, or_connection_t *conn); @@ -620,20 +621,15 @@ command_process_netinfo_cell(cell_t *cell, or_connection_t *conn) /* Act on apparent skew. */ /** Warn when we get a netinfo skew with at least this value. - Ignore if we've already recieved skew info from a trusted dir */ + Ignore if we've already received skew info from a trusted dir */ #define NETINFO_NOTICE_SKEW 3600 if (labs(apparent_skew) > NETINFO_NOTICE_SKEW && router_get_by_digest(conn->identity_digest) && - !received_skew_from_trusted_dir) { + !received_netinfo_from_trusted_dir) { char dbuf[64]; - int severity; /*XXXX be smarter about when everybody says we are skewed. */ - if (router_digest_is_trusted_dir(conn->identity_digest)) { - severity = LOG_WARN; - received_skew_from_trusted_dir = 1; - } - else - severity = LOG_INFO; + int severity = router_digest_is_trusted_dir(conn->identity_digest) ? + LOG_WARN : LOG_INFO; format_time_interval(dbuf, sizeof(dbuf), apparent_skew); log_fn(severity, LD_GENERAL, "Received NETINFO cell with skewed time from " "server at %s:%d. It seems that our clock is %s by %s, or " @@ -647,25 +643,20 @@ command_process_netinfo_cell(cell_t *cell, or_connection_t *conn) "CLOCK_SKEW SKEW=%ld SOURCE=OR:%s:%d", apparent_skew, conn->_base.address, conn->_base.port); - } - else { /* Connect to a trusted dir to trigger a NETINFO cell*/ + } else { /* Connect to a trusted dir to trigger a NETINFO cell*/ routerstatus_t *any_trusted_dir = router_pick_trusteddirserver(NO_AUTHORITY, 0); - const tor_addr_t trusted_dir_addr; + tor_addr_t trusted_dir_addr; tor_addr_from_ipv4n(&trusted_dir_addr, any_trusted_dir->addr); connection_or_connect(&trusted_dir_addr, any_trusted_dir->or_port, any_trusted_dir->descriptor_digest); - } } - /* Mark a flag if we get a good skew from a trusted dir */ - if (labs(apparent_skew) < NETINFO_NOTICE_SKEW && - router_digest_is_trusted_dir(conn->identity_digest) && - !received_skew_from_trusted_dir) { - received_skew_from_trusted_dir = 1; - } + /* Note that we received a netinfo cell from a trusted directory */ + if (router_digest_is_trusted_dir(conn->identity_digest)) + received_netinfo_from_trusted_dir = 1; /* XXX maybe act on my_apparent_addr, if the source is sufficiently * trustworthy. */ @@ -679,4 +670,3 @@ command_process_netinfo_cell(cell_t *cell, or_connection_t *conn) conn->_base.port, (int)conn->link_proto); assert_connection_ok(TO_CONN(conn),time(NULL)); } -

1 0