February 2011 - tor-commits - lists.torproject.org

[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

[tor/master] whitespace fixup
by nickm＠torproject.org 25 Feb '11

25 Feb '11

commit c94f3711ee0eb7b740c7ad48d62c6d42ade863e5 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Feb 25 12:05:33 2011 -0500 whitespace fixup --- src/or/command.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/or/command.c b/src/or/command.c index ef3a559..e026997 100644 --- a/src/or/command.c +++ b/src/or/command.c @@ -650,7 +650,7 @@ command_process_netinfo_cell(cell_t *cell, or_connection_t *conn) 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) { + } 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; @@ -679,3 +679,4 @@ 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

[tor/master] Changes file for altf4's bug1074 stuff
by nickm＠torproject.org 25 Feb '11

25 Feb '11

commit 22810d740c33d71896822ec20d819724a8a38427 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Feb 25 12:12:02 2011 -0500 Changes file for altf4's bug1074 stuff --- changes/launch_authcon_on_skew | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/changes/launch_authcon_on_skew b/changes/launch_authcon_on_skew new file mode 100644 index 0000000..276e860 --- /dev/null +++ b/changes/launch_authcon_on_skew @@ -0,0 +1,7 @@ + o Minor features + - When we get a connection from a non-authority that tells us our + clock is skewed, and we haven't heard about clock skew (or lack + thereof) from an authority, launch a connection to an authority + so we can find out whether we're really skewed. Related to + bug 1074. Patch from "AltF4". +

1 0

[tor/master] Merge branch 'bug1074_launch_conn_on_skew'
by nickm＠torproject.org 25 Feb '11

25 Feb '11

commit a47fdaf9a0563de4b1fff4df8aca69d9a225dd1e Merge: a2a8ade 22810d7 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Feb 25 12:12:44 2011 -0500 Merge branch 'bug1074_launch_conn_on_skew' Fixed conflict on rename of router_get_by_digest->router_get_by_id_digest Conflicts: src/or/command.c changes/launch_authcon_on_skew | 7 ++++++ src/or/command.c | 42 +++++++++++++++++++++++++++++++-------- 2 files changed, 40 insertions(+), 9 deletions(-) diff --combined src/or/command.c index 4b70dee,e026997..a13f9ec --- a/src/or/command.c +++ b/src/or/command.c @@@ -25,7 -25,6 +25,7 @@@ #include "control.h" #include "cpuworker.h" #include "hibernate.h" +#include "nodelist.h" #include "onion.h" #include "relay.h" #include "router.h" @@@ -45,6 -44,13 +45,13 @@@ uint64_t stats_n_destroy_cells_processe 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. + * 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 */ static void command_process_create_cell(cell_t *cell, or_connection_t *conn); @@@ -268,18 -274,15 +275,18 @@@ command_process_create_cell(cell_t *cel } if (circuit_id_in_use_on_orconn(cell->circ_id, conn)) { - routerinfo_t *router = router_get_by_digest(conn->identity_digest); + const node_t *node = node_get_by_id(conn->identity_digest); log_fn(LOG_PROTOCOL_WARN, LD_PROTOCOL, "Received CREATE cell (circID %d) for known circ. " "Dropping (age %d).", cell->circ_id, (int)(time(NULL) - conn->_base.timestamp_created)); - if (router) + if (node) { + char *p = esc_for_log(node_get_platform(node)); log_fn(LOG_PROTOCOL_WARN, LD_PROTOCOL, "Details: nickname \"%s\", platform %s.", - router->nickname, escaped(router->platform)); + node_get_nickname(node), p); + tor_free(p); + } return; } @@@ -621,17 -624,16 +628,16 @@@ command_process_netinfo_cell(cell_t *ce } /* Act on apparent skew. */ - /** Warn when we get a netinfo skew with at least this value. */ + /** Warn when we get a netinfo skew with at least this value. + 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_id_digest(conn->identity_digest)) { - router_get_by_digest(conn->identity_digest) && ++ router_get_by_id_digest(conn->identity_digest) && + received_netinfo_from_trusted_dir != 2) { 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; - 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 " @@@ -640,13 -642,31 +646,31 @@@ conn->_base.address, (int)conn->_base.port, apparent_skew>0 ? "ahead" : "behind", dbuf, apparent_skew>0 ? "behind" : "ahead"); - if (severity == LOG_WARN) /* only tell the controller if an authority */ + if (severity == LOG_WARN) { /* only tell the controller if an authority */ control_event_general_status(LOG_WARN, "CLOCK_SKEW SKEW=%ld SOURCE=OR:%s:%d", apparent_skew, conn->_base.address, conn->_base.port); + 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; + 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->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] Add a missing const
by nickm＠torproject.org 25 Feb '11

25 Feb '11

commit b3d74045ae79544fa8258f54789f83b74851f832 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Feb 25 12:32:29 2011 -0500 Add a missing const --- src/or/command.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/or/command.c b/src/or/command.c index a13f9ec..bfcc1c9 100644 --- a/src/or/command.c +++ b/src/or/command.c @@ -655,7 +655,7 @@ command_process_netinfo_cell(cell_t *cell, or_connection_t *conn) /* 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 = + const routerstatus_t *any_trusted_dir = router_pick_trusteddirserver(NO_AUTHORITY, 0); tor_addr_t trusted_dir_addr; tor_addr_from_ipv4h(&trusted_dir_addr, any_trusted_dir->addr);

1 0

[tor/master] Fix time skew values from untrusted sources
by nickm＠torproject.org 25 Feb '11

25 Feb '11

commit b8bef61a8f7d9b24064be8f2b6a0c6fca58c042d Author: AltF4 <altf4(a)phx2600.org> Date: Wed Feb 9 22:03:53 2011 -0700 Fix time skew values from untrusted sources Now when we receive a large time skew from a source which isn't a trusted dir, we go contact a trusted dir to trigger a NETINFO cell. --- src/or/command.c | 32 ++++++++++++++++++++++++++++---- 1 files changed, 28 insertions(+), 4 deletions(-) diff --git a/src/or/command.c b/src/or/command.c index 00d9af3..abe755e 100644 --- a/src/or/command.c +++ b/src/or/command.c @@ -44,6 +44,8 @@ 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; /* These are the main functions for processing cells */ static void command_process_create_cell(cell_t *cell, or_connection_t *conn); @@ -617,15 +619,19 @@ 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. */ + /** Warn when we get a netinfo skew with at least this value. + Ignore if we've already recieved 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)) { + router_get_by_digest(conn->identity_digest) && + !received_skew_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)) + if (router_digest_is_trusted_dir(conn->identity_digest)) { severity = LOG_WARN; + received_skew_from_trusted_dir = 1; + } else severity = LOG_INFO; format_time_interval(dbuf, sizeof(dbuf), apparent_skew); @@ -636,11 +642,29 @@ command_process_netinfo_cell(cell_t *cell, or_connection_t *conn) conn->_base.address, (int)conn->_base.port, apparent_skew>0 ? "ahead" : "behind", dbuf, apparent_skew>0 ? "behind" : "ahead"); - if (severity == LOG_WARN) /* only tell the controller if an authority */ + if (severity == LOG_WARN) { /* only tell the controller if an authority */ control_event_general_status(LOG_WARN, "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*/ + routerstatus_t *any_trusted_dir = + router_pick_trusteddirserver(NO_AUTHORITY, 0); + const 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; } /* XXX maybe act on my_apparent_addr, if the source is sufficiently

1 0