- tor-commits - lists.torproject.org

[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

[tor/master] Fix handling of StreamID exhaustion.
by nickm＠torproject.org 07 Apr '11

07 Apr '11

commit 432734279d3688fafb466a23f43585ff509ff693 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Mar 25 17:57:15 2011 -0400 Fix handling of StreamID exhaustion. Since svn r1475/git 5b6099e8 in tor-0.0.6, we have responded to an exhaustion of all 65535 stream IDs on a circuit by marking that circuit for close. That's not the right response. Instead, we should mark the circuit as "too dirty for new circuits". Of course in reality this isn't really right either. If somebody has managed to cram 65535 streams onto a circuit, the circuit is probably not going to work well for any of those streams, so maybe we should be limiting the number of streams on an origin circuit concurrently. Also, closing the stream in this case is probably the wrong thing to do as well, but fixing that can also wait. --- changes/full_ap_circuits | 6 ++++++ src/or/connection_edge.c | 18 ++++++++++++++---- 2 files changed, 20 insertions(+), 4 deletions(-) diff --git a/changes/full_ap_circuits b/changes/full_ap_circuits new file mode 100644 index 0000000..379a1a1 --- /dev/null +++ b/changes/full_ap_circuits @@ -0,0 +1,6 @@ + o Minor bugfixes + - When a client finds that an origin circuit has run out of 16-bit + stream IDs, we now mark it as unusable for new streams. + Previously, we would try to close the entire circuit. Bugfix on + Tor version 0.0.6. + diff --git a/src/or/connection_edge.c b/src/or/connection_edge.c index af0cfbe..72e2c8a 100644 --- a/src/or/connection_edge.c +++ b/src/or/connection_edge.c @@ -2164,9 +2164,14 @@ connection_ap_handshake_send_begin(edge_connection_t *ap_conn) ap_conn->stream_id = get_unique_stream_id_by_circ(circ); if (ap_conn->stream_id==0) { + /* XXXX023 Instead of closing this stream, we should make it get + * retried on another circuit. */ connection_mark_unattached_ap(ap_conn, END_STREAM_REASON_INTERNAL); - /*XXXX022 _close_ the circuit because it's full? That sounds dumb. */ - circuit_mark_for_close(TO_CIRCUIT(circ), END_CIRC_REASON_RESOURCELIMIT); + + /* Mark this circuit "unusable for new streams". */ + /* XXXX023 this is a kludgy way to do this. */ + tor_assert(circ->_base.timestamp_dirty); + circ->_base.timestamp_dirty -= get_options()->MaxCircuitDirtiness; return -1; } @@ -2224,9 +2229,14 @@ connection_ap_handshake_send_resolve(edge_connection_t *ap_conn) ap_conn->stream_id = get_unique_stream_id_by_circ(circ); if (ap_conn->stream_id==0) { + /* XXXX023 Instead of closing this stream, we should make it get + * retried on another circuit. */ connection_mark_unattached_ap(ap_conn, END_STREAM_REASON_INTERNAL); - /*XXXX022 _close_ the circuit because it's full? That sounds dumb. */ - circuit_mark_for_close(TO_CIRCUIT(circ), END_CIRC_REASON_RESOURCELIMIT); + + /* Mark this circuit "unusable for new streams". */ + /* XXXX023 this is a kludgy way to do this. */ + tor_assert(circ->_base.timestamp_dirty); + circ->_base.timestamp_dirty -= get_options()->MaxCircuitDirtiness; return -1; }

1 0

[tor/master] Add a missing cast to silence the compiler
by nickm＠torproject.org 07 Apr '11

07 Apr '11

commit 8d81831d715adf9cb374100e23cc2b118efe3101 Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Mon Mar 28 18:20:50 2011 +0200 Add a missing cast to silence the compiler --- src/or/connection.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/or/connection.c b/src/or/connection.c index 084237d..6e7bbd5 100644 --- a/src/or/connection.c +++ b/src/or/connection.c @@ -2790,7 +2790,7 @@ connection_handle_write_impl(connection_t *conn, int force) edge_connection_t *edge_conn = TO_EDGE_CONN(conn); /* Check for overflow: */ if (PREDICT_LIKELY(UINT32_MAX - edge_conn->n_written > n_written)) - edge_conn->n_written += n_written; + edge_conn->n_written += (int)n_written; else edge_conn->n_written = UINT32_MAX; }

1 0

[tor/master] Add XXX023s for our timestamp_dirty abuse.
by nickm＠torproject.org 07 Apr '11

07 Apr '11

commit f3b89c114112987b74bb0632cfe47a3a17859adb Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Mar 25 17:49:44 2011 -0400 Add XXX023s for our timestamp_dirty abuse. --- src/or/circuitlist.c | 3 +++ src/or/connection_edge.c | 2 ++ src/or/or.h | 10 ++++++++-- src/or/relay.c | 2 ++ 4 files changed, 15 insertions(+), 2 deletions(-) diff --git a/src/or/circuitlist.c b/src/or/circuitlist.c index b4f5f45..521c21e 100644 --- a/src/or/circuitlist.c +++ b/src/or/circuitlist.c @@ -1023,6 +1023,7 @@ circuit_mark_all_unused_circs(void) * This is useful for letting the user change pseudonyms, so new * streams will not be linkable to old streams. */ +/* XXX023 this is a bad name for what this function does */ void circuit_expire_all_dirty_circs(void) { @@ -1033,6 +1034,8 @@ circuit_expire_all_dirty_circs(void) if (CIRCUIT_IS_ORIGIN(circ) && !circ->marked_for_close && circ->timestamp_dirty) + /* XXXX023 This is a screwed-up way to say "This is too dirty + * for new circuits. */ circ->timestamp_dirty -= options->MaxCircuitDirtiness; } } diff --git a/src/or/connection_edge.c b/src/or/connection_edge.c index c75c06b..af0cfbe 100644 --- a/src/or/connection_edge.c +++ b/src/or/connection_edge.c @@ -517,6 +517,7 @@ connection_ap_expire_beginning(void) /* kludge to make us not try this circuit again, yet to allow * current streams on it to survive if they can: make it * unattractive to use for new streams */ + /* XXXX023 this is a kludgy way to do this. */ tor_assert(circ->timestamp_dirty); circ->timestamp_dirty -= options->MaxCircuitDirtiness; /* give our stream another 'cutoff' seconds to try */ @@ -2164,6 +2165,7 @@ connection_ap_handshake_send_begin(edge_connection_t *ap_conn) ap_conn->stream_id = get_unique_stream_id_by_circ(circ); if (ap_conn->stream_id==0) { connection_mark_unattached_ap(ap_conn, END_STREAM_REASON_INTERNAL); + /*XXXX022 _close_ the circuit because it's full? That sounds dumb. */ circuit_mark_for_close(TO_CIRCUIT(circ), END_CIRC_REASON_RESOURCELIMIT); return -1; } diff --git a/src/or/or.h b/src/or/or.h index 124892c..e44c626 100644 --- a/src/or/or.h +++ b/src/or/or.h @@ -2127,8 +2127,14 @@ typedef struct circuit_t { char *n_conn_onionskin; time_t timestamp_created; /**< When was this circuit created? */ - time_t timestamp_dirty; /**< When the circuit was first used, or 0 if the - * circuit is clean. */ + /** When the circuit was first used, or 0 if the circuit is clean. + * + * XXXX023 Note that some code will artifically adjust this value backward + * in time in order to indicate that a circuit shouldn't be used for new + * streams, but that it can stay alive as long as it has streams on it. + * That's a kludge we should fix. + */ + time_t timestamp_dirty; struct timeval highres_created; /**< When exactly was the circuit created? */ uint16_t marked_for_close; /**< Should we close this circuit at the end of diff --git a/src/or/relay.c b/src/or/relay.c index 076b46b..807cb3d 100644 --- a/src/or/relay.c +++ b/src/or/relay.c @@ -791,6 +791,8 @@ connection_ap_process_end_not_open( < MAX_RESOLVE_FAILURES) { /* We haven't retried too many times; reattach the connection. */ circuit_log_path(LOG_INFO,LD_APP,circ); + /* Mark this circuit "unusable for new streams". */ + /* XXXX023 this is a kludgy way to do this. */ tor_assert(circ->_base.timestamp_dirty); circ->_base.timestamp_dirty -= get_options()->MaxCircuitDirtiness;

1 0

[tor/master] Improve a few comments
by nickm＠torproject.org 07 Apr '11

07 Apr '11

commit 9facf8918f959cc9d9c2674afbd0630718460dc3 Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Mon Mar 28 19:28:04 2011 +0200 Improve a few comments --- src/common/address.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/common/address.c b/src/common/address.c index a089260..adc0ef0 100644 --- a/src/common/address.c +++ b/src/common/address.c @@ -51,11 +51,11 @@ /** Convert the tor_addr_t in <b>a</b>, with port in <b>port</b>, into a * sockaddr object in *<b>sa_out</b> of object size <b>len</b>. If not enough - * room is available in sa_out, or on error, return 0 On success, return + * room is available in sa_out, or on error, return 0. On success, return * the length of the sockaddr. * - * Interface note: ordinarly, we return -1 for error. We can't do that here, - * since socklen is unsigned on some platforms. + * Interface note: ordinarily, we return -1 for error. We can't do that here, + * since socklen_t is unsigned on some platforms. **/ socklen_t tor_addr_to_sockaddr(const tor_addr_t *a,

1 0