- tor-commits - lists.torproject.org

[tor/master] Merge remote-tracking branch 'origin/maint-0.2.2'
by nickm＠torproject.org 08 Apr '11

08 Apr '11

commit 99c2bfe76b48f8a142682c2729236d5e4e63ec25 Merge: 85ac832 e247705 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Apr 8 13:37:57 2011 -0400 Merge remote-tracking branch 'origin/maint-0.2.2' Conflicts: src/or/rephist.c src/common/log.c | 11 ++++++++++- src/or/rephist.c | 19 +++++++++++++++++-- 2 files changed, 27 insertions(+), 3 deletions(-) diff --cc src/or/rephist.c index 56a3d1d,9b7eefe..d6b4a03 --- a/src/or/rephist.c +++ b/src/or/rephist.c @@@ -2748,6 -2545,11 +2756,13 @@@ rep_hist_free_all(void tor_free(exit_streams); built_last_stability_doc_at = 0; predicted_ports_free(); + bidi_map_free(); ++ + if (circuits_for_buffer_stats) { + SMARTLIST_FOREACH(circuits_for_buffer_stats, circ_buffer_stats_t *, s, + tor_free(s)); + smartlist_free(circuits_for_buffer_stats); + circuits_for_buffer_stats = NULL; + } }

1 0

[tor/maint-0.2.2] Fix up some cell-queue stats issues in rephist.c
by nickm＠torproject.org 08 Apr '11

08 Apr '11

commit 71fb2af62c0a60fee94f984b782531a5d492b055 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Apr 7 14:56:50 2011 -0400 Fix up some cell-queue stats issues in rephist.c - Document the structure and variables. - Make circuits_for_buffer_stats into a static variable. - Don't die horribly if interval_length is 0. - Remove the unused local_circ_id field. - Reorder the fields of circ_buffer_stats_t for cleaner alignment layout. --- src/or/rephist.c | 13 ++++++++++--- 1 files changed, 10 insertions(+), 3 deletions(-) diff --git a/src/or/rephist.c b/src/or/rephist.c index e56ce9e..74e156f 100644 --- a/src/or/rephist.c +++ b/src/or/rephist.c @@ -2330,14 +2330,19 @@ rep_hist_buffer_stats_init(time_t now) start_of_buffer_stats_interval = now; } +/** Statistics from a single circuit. Collected when the circuit closes, or + * when we flush statistics to disk. */ typedef struct circ_buffer_stats_t { - uint32_t processed_cells; + /** Average number of cells in the circuit's queue */ double mean_num_cells_in_queue; + /** Average time a cell waits in the queue. */ double mean_time_cells_in_queue; - uint32_t local_circ_id; + /** Total number of cells sent over this circuit */ + uint32_t processed_cells; } circ_buffer_stats_t; -smartlist_t *circuits_for_buffer_stats = NULL; +/** List of circ_buffer_stats_t. */ +static smartlist_t *circuits_for_buffer_stats = NULL; /** Remember cell statistics for circuit <b>circ</b> at time * <b>end_of_interval</b> and reset cell counters in case the circuit @@ -2361,6 +2366,8 @@ rep_hist_buffer_stats_add_circ(circuit_t *circ, time_t end_of_interval) circ->timestamp_created.tv_sec : start_of_buffer_stats_interval; interval_length = (int) (end_of_interval - start_of_interval); + if (interval_length <= 0) + return; stat = tor_malloc_zero(sizeof(circ_buffer_stats_t)); stat->processed_cells = orcirc->processed_cells; /* 1000.0 for s -> ms; 2.0 because of app-ward and exit-ward queues */

1 0

[tor/maint-0.2.2] Free circuits_for_buffer_stats on shutdown
by nickm＠torproject.org 08 Apr '11

08 Apr '11

commit 403b6cfdedee7ebc8fe0b5d1c187e8ae3611aec1 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Apr 7 14:59:28 2011 -0400 Free circuits_for_buffer_stats on shutdown --- src/or/rephist.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/or/rephist.c b/src/or/rephist.c index 74e156f..9b7eefe 100644 --- a/src/or/rephist.c +++ b/src/or/rephist.c @@ -2545,5 +2545,11 @@ rep_hist_free_all(void) tor_free(exit_streams); built_last_stability_doc_at = 0; predicted_ports_free(); + if (circuits_for_buffer_stats) { + SMARTLIST_FOREACH(circuits_for_buffer_stats, circ_buffer_stats_t *, s, + tor_free(s)); + smartlist_free(circuits_for_buffer_stats); + circuits_for_buffer_stats = NULL; + } }

1 0

[tor/maint-0.2.2] Free pending_cb_messages on exit
by nickm＠torproject.org 08 Apr '11

08 Apr '11

commit 1be12213857e3c5068107f4df047cea03b6462e8 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Apr 7 15:25:33 2011 -0400 Free pending_cb_messages on exit --- src/common/log.c | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/src/common/log.c b/src/common/log.c index 28d0029..d14563c 100644 --- a/src/common/log.c +++ b/src/common/log.c @@ -363,7 +363,7 @@ logv(int severity, log_domain_mask_t domain, const char *funcname, continue; } else if (lf->callback) { if (domain & LD_NOCB) { - if (!callbacks_deferred) { + if (!callbacks_deferred && pending_cb_messages) { pending_cb_message_t *msg = tor_malloc(sizeof(pending_cb_message_t)); msg->severity = severity; msg->domain = domain; @@ -512,9 +512,12 @@ void logs_free_all(void) { logfile_t *victim, *next; + smartlist_t *messages; LOCK_LOGS(); next = logfiles; logfiles = NULL; + messages = pending_cb_messages; + pending_cb_messages = NULL; UNLOCK_LOGS(); while (next) { victim = next; @@ -524,6 +527,12 @@ logs_free_all(void) } tor_free(appname); + SMARTLIST_FOREACH(messages, pending_cb_message_t *, msg, { + tor_free(msg->msg); + tor_free(msg); + }); + smartlist_free(messages); + /* We _could_ destroy the log mutex here, but that would screw up any logs * that happened between here and the end of execution. */ }

1 0

[tor/maint-0.2.2] Merge branch 'bug2373' into maint-0.2.2
by nickm＠torproject.org 08 Apr '11

08 Apr '11

commit e247705afefaa0f32ccbc43185f98fc65f041af1 Merge: 70e0291 1be1221 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Apr 8 13:35:26 2011 -0400 Merge branch 'bug2373' into maint-0.2.2 src/common/log.c | 11 ++++++++++- src/or/rephist.c | 19 ++++++++++++++++--- 2 files changed, 26 insertions(+), 4 deletions(-)

1 0

[tor/master] Use GetTempDir instead of hardcoded path to c:\windows\tmp for unittests
by nickm＠torproject.org 08 Apr '11

08 Apr '11

commit 70e02914682eb1959d8b385f76b5acf7486158cc Author: Gisle Vanem <gvanem(a)broadpark.no> Date: Thu Apr 7 18:34:11 2011 -0400 Use GetTempDir instead of hardcoded path to c:\windows\tmp for unittests --- changes/win_tmp_dir | 4 ++++ src/test/test.c | 14 ++++++++++---- 2 files changed, 14 insertions(+), 4 deletions(-) diff --git a/changes/win_tmp_dir b/changes/win_tmp_dir new file mode 100644 index 0000000..13f6e7f --- /dev/null +++ b/changes/win_tmp_dir @@ -0,0 +1,4 @@ + o Unit tests: + - Use GetTempDir to find the proper temporary directory location on + Windows when generating temporary files for the unit tests. Patch + by Gisle Vanem. diff --git a/src/test/test.c b/src/test/test.c index f5b6a22..9b24a99 100644 --- a/src/test/test.c +++ b/src/test/test.c @@ -84,10 +84,16 @@ setup_directory(void) if (is_setup) return; #ifdef MS_WINDOWS - // XXXX - tor_snprintf(temp_dir, sizeof(temp_dir), - "c:\\windows\\temp\\tor_test_%d", (int)getpid()); - r = mkdir(temp_dir); + { + char buf[MAX_PATH]; + const char *tmp = buf; + /* If this fails, we're probably screwed anyway */ + if (!GetTempPath(sizeof(buf),buf)) + tmp = "c:\\windows\\temp"; + tor_snprintf(temp_dir, sizeof(temp_dir), + "%s\\tor_test_%d", tmp, (int)getpid()); + r = mkdir(temp_dir); + } #else tor_snprintf(temp_dir, sizeof(temp_dir), "/tmp/tor_test_%d", (int) getpid()); r = mkdir(temp_dir, 0700);

1 0

[tor/master] Merge remote-tracking branch 'origin/maint-0.2.2'
by nickm＠torproject.org 08 Apr '11

08 Apr '11

commit 85ac832a1474e274ff4a6ad9444cf5e0ab12450e Merge: 67d88a7 70e0291 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Apr 7 20:27:39 2011 -0400 Merge remote-tracking branch 'origin/maint-0.2.2' changes/win_tmp_dir | 4 ++++ src/test/test.c | 14 ++++++++++---- 2 files changed, 14 insertions(+), 4 deletions(-)

1 0

[tor/maint-0.2.2] Use GetTempDir instead of hardcoded path to c:\windows\tmp for unittests
by nickm＠torproject.org 08 Apr '11

08 Apr '11

commit 70e02914682eb1959d8b385f76b5acf7486158cc Author: Gisle Vanem <gvanem(a)broadpark.no> Date: Thu Apr 7 18:34:11 2011 -0400 Use GetTempDir instead of hardcoded path to c:\windows\tmp for unittests --- changes/win_tmp_dir | 4 ++++ src/test/test.c | 14 ++++++++++---- 2 files changed, 14 insertions(+), 4 deletions(-) diff --git a/changes/win_tmp_dir b/changes/win_tmp_dir new file mode 100644 index 0000000..13f6e7f --- /dev/null +++ b/changes/win_tmp_dir @@ -0,0 +1,4 @@ + o Unit tests: + - Use GetTempDir to find the proper temporary directory location on + Windows when generating temporary files for the unit tests. Patch + by Gisle Vanem. diff --git a/src/test/test.c b/src/test/test.c index f5b6a22..9b24a99 100644 --- a/src/test/test.c +++ b/src/test/test.c @@ -84,10 +84,16 @@ setup_directory(void) if (is_setup) return; #ifdef MS_WINDOWS - // XXXX - tor_snprintf(temp_dir, sizeof(temp_dir), - "c:\\windows\\temp\\tor_test_%d", (int)getpid()); - r = mkdir(temp_dir); + { + char buf[MAX_PATH]; + const char *tmp = buf; + /* If this fails, we're probably screwed anyway */ + if (!GetTempPath(sizeof(buf),buf)) + tmp = "c:\\windows\\temp"; + tor_snprintf(temp_dir, sizeof(temp_dir), + "%s\\tor_test_%d", tmp, (int)getpid()); + r = mkdir(temp_dir); + } #else tor_snprintf(temp_dir, sizeof(temp_dir), "/tmp/tor_test_%d", (int) getpid()); r = mkdir(temp_dir, 0700);

1 0

[metrics-web/master] Add Roger's blog post to the papers page.
by karsten＠torproject.org 07 Apr '11

07 Apr '11

commit 2d1a8c13b918b5c411a3e2756e3172aed31dbd97 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Thu Apr 7 21:32:45 2011 +0200 Add Roger's blog post to the papers page. --- web/WEB-INF/papers.jsp | 21 +++++++++++++++++---- 1 files changed, 17 insertions(+), 4 deletions(-) diff --git a/web/WEB-INF/papers.jsp b/web/WEB-INF/papers.jsp index 1880483..50f8bda 100644 --- a/web/WEB-INF/papers.jsp +++ b/web/WEB-INF/papers.jsp @@ -12,10 +12,11 @@ <div class="main-column"> <h2>Tor Metrics Portal: Papers</h2> <br> - <p>The <a href="#papers">papers</a> and - <a href="#techreports">technical reports</a> listed on this page - originate from, or are based on, work performed in the Tor Metrics - Project.</p> + <p>The <a href="#papers">papers</a>, + <a href="#techreports">technical reports</a>, and + <a href="#blogposts">blog posts</a> listed on this page originate + from, are based on, or are related to work performed in the Tor + Metrics Project.</p> <br> <a name="papers"></a> <h3>Papers</h3> @@ -81,6 +82,18 @@ (<a href="papers/dirarch-2009-06-22.pdf">PDF</a>, 558K, last updated on June 22, 2009).</li> </ul> + <br> + <a name="blogposts"></a> + <h3>Blog posts</h3> + <br> + The following blog posts are either the results of metrics + research or describe new interesting research questions that can + (partly) be answered with metrics data. + <ul> + <li>Research problem: measuring the safety of the Tor network + (<a href="https://blog.torproject.org/blog/research-problem-measuring-safety-tor-netw…">link</a>, + February 5, 2011).</li> + </ul> </div> </div> <div class="bottom" id="bottom">

1 0

[torspec/master] add mike's triangle boy analysis
by arma＠torproject.org 07 Apr '11

07 Apr '11

commit 3b5b8804f64a4db7ec7fc0185ea1afb7a2713797 Author: Roger Dingledine <arma(a)torproject.org> Date: Thu Apr 7 12:35:28 2011 -0400 add mike's triangle boy analysis --- proposals/ideas/xxx-triangleboy-transport.txt | 194 +++++++++++++++++++++++++ 1 files changed, 194 insertions(+), 0 deletions(-) diff --git a/proposals/ideas/xxx-triangleboy-transport.txt b/proposals/ideas/xxx-triangleboy-transport.txt new file mode 100644 index 0000000..e09eaac --- /dev/null +++ b/proposals/ideas/xxx-triangleboy-transport.txt @@ -0,0 +1,194 @@ +[See also http://archives.seul.org/tor/dev/Feb-2011/msg00000.html and +its follow-ups.] + +Filename: ideas/xxx-triangleboy-transport.txt +Title: The Triangle Boy Transport +Author: Mike Perry +Created: 31-Jan-2011 +Status: Draft + + +Introduction + +In this proposal, we describe a transport plugin known as the Triangle +Boy transport: +http://www.webrant.com/safeweb_site/html/www/tboy_whitepaper.html + +The basic idea is to be able to utilize an asymmetric residential IP +with minimal CPU and memory resources, and limited upstream. We would +use the bridge for only half of the stream, avoiding the upstream +bottleneck of most residential connections. The return direction +will be spoofed by a supporting high-capacity Tor relay. + + +Overview + +The high level packet flow diagram would look like this. + + Client -> Client Plugin -> Transport Bridge -> Relay Plugin -> Relay + Client <- Client Plugin <--(spoof)--- Relay Plugin <- Relay + +Testing in the field has demonstrated that most residential +connections also perform egress filtering, where as many colo centers +do not. This means that the spoofing logic needs to be present at the +Relay endpoint, and not in the Transport Bridge (though the Transport +Bridge will still need raw sockets to listen for TCP fragments). + +It is this egress filter constraint that requires that this transport +use the pluggable-transport spec, as opposed to creating a very simple +spoofing Transport Bridge. + +There are two possible designs for the operation of the Transport +Bridge. The bridge can either be peered with a relay of its choosing, +or it can be peered with a client-specified relay. Since using a +client-specified relay in a censored location is prone to failure due +to unobservable changing network conditions, we will consider the case +where the Transport Bridge chooses which relay to forward the +connections to. + +The client will use the Transport Bridge IP with a bridge line like: + "bridge TriangleBoy address:port" + +On the client side, the TriangleBoy transport keyword would only mean +that the Tor client should not try to cache the identity key of the +bridge in question, nor should it perform any strict checks to ensure +that the IP reported by the relay is consistent or matches its +endpoint. + +Other than these basic loosened constraints, it should be able to use +the Transport Bridge IP as if it were any other bridge. This is +uniquely different from the what the pluggable-transport spec assumes. +Most of the complexity involved in supporting this transport will be +in the Transport Bridge, and in the Relay Plugin side of the equation. + + +Transport Bridge Operation + +The Transport Bridge will require raw sockets to operate. It will also +require a tor client to fetch and authenticate the Tor directory. + +The current pluggable transport spec suggests that extrainfo +descriptors be used to describe which transport plugins a bridge +supports. This would require that the Transport Bridge set +DownloadExtraInfo=1 in its torrc. + +The extrainfo document would need to list the following information: +TriangleBoyTransport ip:port +TriangleBoyCert <Certificate> + +The Transport Bridge would attempt to select an appropriate relay or +relays to forward all client connections. + +The forwarding operation by the Transport Bridge would involve a TLS +connection to the ip and port specified in the extrainfo document and +authenticated by the certificate there, and speak cells of the +following format: + + <data_len>: 2 bytes + <data>: data_len bytes + +Each new raw TCP packet that arrives at the transport bridge would be +packaged up according to this scheme. The data portion of the packet +would be the raw IP frame received by the transport bridge. + +The TLS connection can be reused to multiplex many different raw +datagrams for many different clients. + + +Relay Plugin Startup + +Not all relays can support the TriangleBoy transport. Many relays are +behind egress filters that will prevent the transmission of spoofed +packets. The transport plugin should be robust enough to be able to +determine if it can properly spoof the packets. This involves both +ensuring that the plugin process has sufficient permissions, and also +sending some spoofed test packets to a server to receive the response. + +If either of these tests fail, the plugin needs to inform Tor of this +fact so that Tor does *not* provide the lines for the TriangleBoy +transport in its extrainfo document. + +The relay would configure the plugin using its torrc: + +ServerTransportPlugin TriangleBoy /path/to/triangleboy ip=<ip> port=<port> \ + tor_ip=<ip> tor_port=<port> free_rfc1918=<ip> + +Tor would launch the triangleboy process, which would perform the +appropriate uid checks, and send test spoofed packets to $SERVER (the +bridgedb?). If the tests pass, it would reply with: + +SMETHOD: TriangleBoy <ip>:<port> \ + EXTRAINFO:TriangleBoyTransport=<ip>:<port>,TriangleBoyCert=<Certificate> +METHODS: DONE + +If there are any errors with permissions or spoofing, the transport +should reply with: + +METHODS: NONE + +and then exit. + + +Relay Plugin Operation + +The relay plugin will listen for TLS connections on its port, using +the certificate it created and sent to Tor during startup. + +It will perform some verification on the integrity of incoming +datagrams: ensuring that they are in fact TCP/IP, that their destination +IP was in fact the Transport Bridge, and that their source IP is in +publicly routable IP space. + +It would then perform a form of NAT in order to translate the raw IP +frames coming in to be sourced from the free_rfc1918 IP (specified in +the configuration line) and a random free port. It will maintain an +internal mapping between these randomized local source ports and the +originating Client IP and port (as well as the Transport Bridge IP). + +The Relay will then proceed believing that it has a TCP connection +from an unused, local rfc1918 ip and source port. This ip+port will +not actually exist, but instead will be handled by a raw socket +listening in the Relay Plugin. + +Upon receiving packets from the Tor process on its raw socket, the +Relay Plugin will use the destination port to look up the original +Client IP and port, and the Transport Bridge IP. It will rewrite the +packets to spoof the source IP as the Transport Bridge IP, and set the +destination IP and port as the one it found for the Client in the its +NAT table. + +In this way, the NAT will properly seamlessly translate packets for +the Relay, and the Client will communicate with what it believes to be +the Transport Bridge IP, while using the capacity of the supporting +Tor Relay for the downstream direction. + + +Appendix: List of key xxx-pluggable-transport.txt shortcomings + +1. This pluggable transport does not need any intelligence or process +launching on the Client side, aside from a way to tell Tor not to be +so pedantic about ensuring identity key and IP address consistency. + +2. The relay side needs to be able to detect if it has both the +permissions and the network ability to send spoofed packets. It needs +to communicate this fact with the Relay Plugin by responding with the +appropriate extrainfo lines, or with "METHODS: NONE" to indicate +error. This relay-side handshake should be specified in the +pluggable-transport spec. + +3. The relay plugin side needs some way to communicate EXTRAINFO lines +to be added to its extrainfo descriptor. In this proposal, we use the +SMETHOD reply to do this. + +4. Is extrainfo really the best place to keep this information? +Shouldn't it just be in the relay/bridge descriptor? Putting it in +extrainfo requires our TransportBridges to enable the wasteful +DownloadExtraInfo=1 torrc setting, which will consume more scarce +resources and RAM on what will probably be cheap routers with 32-64M +of RAM. + +5. How would we go about chaining an actual obfuscation mechanism with +this transport? Would we just create new and separate transport called +TriangleBoyOverHTTP, for example, or is there a better way to chain +different mechanisms? +

1 0