tor-commits

tor-commits@lists.torproject.org

1 participants
212404 discussions

[tor/master] Clarify threat description and avoid negative uptimes.
by nickm＠torproject.org 12 Mar '11

12 Mar '11

commit 3a0c6021556abc96f4c610d5e097e3890216595f Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Mar 11 13:03:25 2011 -0500 Clarify threat description and avoid negative uptimes. --- changes/hsdir_assignment | 7 ++++--- src/or/rephist.c | 2 +- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/changes/hsdir_assignment b/changes/hsdir_assignment index ba01990..5c04b9b 100644 --- a/changes/hsdir_assignment +++ b/changes/hsdir_assignment @@ -2,6 +2,7 @@ - Directory authorities now use data collected from rephist when choosing whether to assign the HSDir flag to relays, instead of trusting the uptime value the relay reports in its descriptor. - This helps prevent an attack where relatively few malaicious - nodes can blackhole any given hidden service. Bugfix on - 0.2.0.10-alpha; fixes bug 2709. + This helps prevent an attack where a small set of nodes with + frequently-changing identity keys can blackhole a hidden service. + (Only authorities need upgrade; others will be fine once they do.) + Bugfix on 0.2.0.10-alpha; fixes bug 2709. diff --git a/src/or/rephist.c b/src/or/rephist.c index 69001de..e4afe62 100644 --- a/src/or/rephist.c +++ b/src/or/rephist.c @@ -537,7 +537,7 @@ rep_hist_get_uptime(const char *id, time_t when) or_history_t *hist = get_or_history(id); if (!hist) return 0; - if (!hist->start_of_run) + if (!hist->start_of_run || when < hist->start_of_run) return 0; return when - hist->start_of_run; }

1 0

[tor/master] Merge branch 'hsdir_assignment' into maint-0.2.2
by nickm＠torproject.org 12 Mar '11

12 Mar '11

commit d34a5cdc597824e72453009ed209e5644f158e90 Merge: 600ad7b 3a0c602 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Mar 11 23:30:25 2011 -0500 Merge branch 'hsdir_assignment' into maint-0.2.2 changes/hsdir_assignment | 8 ++++++++ src/or/dirserv.c | 19 ++++++++++++++++++- src/or/rephist.c | 14 ++++++++++++++ src/or/rephist.h | 1 + 4 files changed, 41 insertions(+), 1 deletions(-)

1 0

[tor/maint-0.2.2] Use observed instead of declared uptime for HSDir
by nickm＠torproject.org 12 Mar '11

12 Mar '11

commit f7a3cdc8f27c2306cf06d742af63846c82ebdc56 Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Wed Mar 9 11:34:04 2011 +0100 Use observed instead of declared uptime for HSDir It is important to verify the uptime claim of a relay instead of just trusting it, otherwise it becomes too easy to blackhole a specific hidden service. rephist already has data available that we can use here. Bugfix on 0.2.0.10-alpha. --- changes/hsdir_assignment | 7 +++++++ src/or/dirserv.c | 19 ++++++++++++++++++- src/or/rephist.c | 14 ++++++++++++++ src/or/rephist.h | 1 + 4 files changed, 40 insertions(+), 1 deletions(-) diff --git a/changes/hsdir_assignment b/changes/hsdir_assignment new file mode 100644 index 0000000..ba01990 --- /dev/null +++ b/changes/hsdir_assignment @@ -0,0 +1,7 @@ + o Security fixes: + - Directory authorities now use data collected from rephist when + choosing whether to assign the HSDir flag to relays, instead of + trusting the uptime value the relay reports in its descriptor. + This helps prevent an attack where relatively few malaicious + nodes can blackhole any given hidden service. Bugfix on + 0.2.0.10-alpha; fixes bug 2709. diff --git a/src/or/dirserv.c b/src/or/dirserv.c index aeeab45..40136a1 100644 --- a/src/or/dirserv.c +++ b/src/or/dirserv.c @@ -43,6 +43,8 @@ extern time_t time_of_process_start; /* from main.c */ +extern long stats_n_seconds_working; /* from main.c */ + /** Do we need to regenerate the v1 directory when someone asks for it? */ static time_t the_directory_is_dirty = 1; /** Do we need to regenerate the v1 runningrouters document when somebody @@ -1775,7 +1777,22 @@ dirserv_thinks_router_is_unreliable(time_t now, static int dirserv_thinks_router_is_hs_dir(routerinfo_t *router, time_t now) { - long uptime = real_uptime(router, now); + + long uptime; + + /* If we haven't been running for at least + * get_options()->MinUptimeHidServDirectoryV2 seconds, we can't + * have accurate data telling us a relay has been up for at least + * that long. We also want to allow a bit of slack: Reachability + * tests aren't instant. If we haven't been running long enough, + * trust the relay. */ + + if (stats_n_seconds_working > + get_options()->MinUptimeHidServDirectoryV2 * 1.1) + uptime = MIN(rep_hist_get_uptime(router->cache_info.identity_digest, now), + real_uptime(router, now)); + else + uptime = real_uptime(router, now); /* XXX We shouldn't need to check dir_port, but we do because of * bug 1693. In the future, once relays set wants_to_be_hs_dir diff --git a/src/or/rephist.c b/src/or/rephist.c index 53214d6..69001de 100644 --- a/src/or/rephist.c +++ b/src/or/rephist.c @@ -528,6 +528,20 @@ get_weighted_fractional_uptime(or_history_t *hist, time_t when) return ((double) up) / total; } +/** Return how long the router whose identity digest is <b>id</b> has + * been reachable. Return 0 if the router is unknown or currently deemed + * unreachable. */ +long +rep_hist_get_uptime(const char *id, time_t when) +{ + or_history_t *hist = get_or_history(id); + if (!hist) + return 0; + if (!hist->start_of_run) + return 0; + return when - hist->start_of_run; +} + /** Return an estimated MTBF for the router whose identity digest is * <b>id</b>. Return 0 if the router is unknown. */ double diff --git a/src/or/rephist.h b/src/or/rephist.h index 5f6b9f9..b06a39e 100644 --- a/src/or/rephist.h +++ b/src/or/rephist.h @@ -40,6 +40,7 @@ int rep_hist_record_mtbf_data(time_t now, int missing_means_down); int rep_hist_load_mtbf_data(time_t now); time_t rep_hist_downrate_old_runs(time_t now); +long rep_hist_get_uptime(const char *id, time_t when); double rep_hist_get_stability(const char *id, time_t when); double rep_hist_get_weighted_fractional_uptime(const char *id, time_t when); long rep_hist_get_weighted_time_known(const char *id, time_t when);

1 0

[tor/maint-0.2.2] Merge branch 'hsdir_assignment' into maint-0.2.2
by nickm＠torproject.org 12 Mar '11

12 Mar '11

1 0

[tor/maint-0.2.2] Clarify threat description and avoid negative uptimes.
by nickm＠torproject.org 12 Mar '11

12 Mar '11

1 0

[torspec/master] Finish writing all parts of the pluggable transport doc. Needs another edit.
by nickm＠torproject.org 12 Mar '11

12 Mar '11

commit dfc115e2325745da7438b5a787ec7026d11df4e7 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Mar 11 23:23:25 2011 -0500 Finish writing all parts of the pluggable transport doc. Needs another edit. --- proposals/ideas/xxx-pluggable-transport.txt | 255 +++++++++++++++++++++++---- 1 files changed, 221 insertions(+), 34 deletions(-) diff --git a/proposals/ideas/xxx-pluggable-transport.txt b/proposals/ideas/xxx-pluggable-transport.txt index c23ba92..92c14ef 100644 --- a/proposals/ideas/xxx-pluggable-transport.txt +++ b/proposals/ideas/xxx-pluggable-transport.txt @@ -172,29 +172,48 @@ Specifications: Client behavior exec /usr/libexec/tor-proxies/trebuchet [options]", and tells Tor to launch an external program on-demand to provide a socks proxy for 'trebuchet' 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] + external program with a given set of options, even if the same + executable and options are listed for more than one method. + + If instead of a transport name, the torrc lists "*" for a managed proxy, + tor uses that proxy for all transports that it supports. The same program can implement a managed or an external proxy: it just needs to take an argument saying which one to be. Client proxy behavior - When launched from the command-line by a Tor client, a transport - proxy needs to tell Tor which methods and ports it supports. It does - this by printing one or more CMETHOD: lines to its stdout. These look - like + When the Tor client launches a client proxy from the command line, it + sets the environment variable + "CLIENT_TRANSPORT_VER=1" + to tell the proxy which versions of this configuration protocol + it supports. Future versions will give a comma-separated list. + + The Tor client also sets the environment variable + CLIENT_TRANSPORTS to a comma-separated list of which methods this + client should enable, or * if all methods should be enabled. + + The Tor client also sets STATE_LOCATION to a directory where + where the proxy should store state, if it wants to. + + The transport proxy replies by printing "VERSION: 1\n" to its + stdout to say that it supports this protocol. It must either + pick a version that Tor told it about, or pick no version at all, + and say "ERROR: no-version\n" and exit. - CMETHOD: trebuchet SOCKS5 127.0.0.1:19999 ARGS:rocks,height \ - OPT-ARGS:tensile-strength + It then needs to tell Tor which methods and ports it + supports. It does this by printing zero or more CMETHOD: lines + to its stdout. These look like + + CMETHOD: trebuchet SOCKS5 127.0.0.1:19999 ARGS=rocks,height \ + OPT-ARGS=tensile-strength The ARGS field lists mandatory parameters that must appear in every bridge line for this method. The OPT-ARGS field lists optional parameters. If no ARGS or OPT-ARGS field is provided, Tor should not check the parameters in bridge lines for this method. - The proxy should print a single "METHODS: DONE" line after it is + The proxy should print a single "CMETHODS: DONE" line after it is finished telling Tor about the methods it provides. The transport proxy MUST exit cleanly when it receives a SIGTERM from @@ -213,43 +232,216 @@ Client proxy behavior is both listed as a possible method for that proxy in torrc, and it is listed by the proxy as a method it supports. - [XXXX say something about versioning.] +Manually configuring a client proxy for a bridge + + All clients will support the methods "socks4" and "socks5". Users can use + these to configure a local proxy that doesn't support this plug-in + infrastructure method; developers can use them to test new proxies before + they have added support for this plug-in in. + + A bridge configured with these methods looks like: + + bridge socks4 www.example.com:8888 keyid=(fingerprint) \ + proxy=127.0.0.1:9999 auth=xyz + + or + + bridge socks5 www.example.com:8888 keyid=(fingerprint) \ + proxy=127.0.0.1:9999 user=x password=y + + The "proxy" argument for these methods is mandatory: it specifies a proxy + to use when talking to the bridge. The auth or user/password arguments for + these methods are optional: they are passed to the proxy either as its + authentication part (for socks4) or its username/password part (for + socks5). + + The socks4 method uses SOCKS4 if the bridge is given as an IP + address, and SOCKS4A if the bridge is given as a hostname. + + [We'll want to implement this part first, since it lets us test out + per-bridge proxies, albeit with a user-unfriendly manner.] Server behavior - Server proxies are configured similarly to client proxies. + Server proxies are configured similarly to client proxies. When + launching a proxy, the server must tell it what ORPort it has + configured, and what address (if any) it can listen on. The + server must tell the proxy which (if any) methods it should + provide if it can; the proxy needs to tell the server which + methods it is actually providing, and on what ports. + + When a client connects to the proxy, the proxy may need a way to + tell the server some identifier for the client address. It does + this in-band. + + As before, the server lists proxies in its torrc. These can be + external proxies that run on their own, or managedproxies that Tor + launches. + + An external proxy is configured as + + ServerTransportPlugin trebuchet address:port [options] -- param=val param=val... + + A managed proxy is configured as + + ServerTransportPlugin trebuchet exec /path/to/binary [options] + or + ServerTransportPlugin * exec /path/to/binary [options] + The param=val pairs in the external proxy configuration, and the address, + are advertised to make our bridge configuration. + + When possible, Tor should launch only one binary of each binary/option + pair configured. So if the torrc contains + + ClientTransportPlugin foo exec /usr/bin/megaproxy --foo + ClientTransportPlugin bar exec /usr/bin/megaproxy --bar + ServerTransportPlugin * exec /usr/bin/megaproxy --foo + + then Tor will launch the megaproxy binary twice: once with the option + --foo and once with the option --bar. + + When the server launches managed binaries, it sets these environment + variables: + SERVER_TRANSPORT_VER=1 + (As CLIENT_TRANPORT_VER) + + EXT_SERVER_PORT=addr:portnum + (A port on localhost that speaks the extended server protocol) + + ORPORT=addr:portnum + (Our regular orport in a form suitable for local connections) + + BINDADDR=addr + (An address on which to listen to connections. This might be the + advertised address, or might be a local address that Tor will + forward ports to.) + + SERVER_TRANSPORTS=... + (A comma-separated list of server methods that the proxy + should support, or *). + + STATE_LOCATION=... + (A directory where where the proxy should store state, if it + wants to.) - + It also opens an extending server port as described below. Server proxy behavior + The server proxy communicates with the server as the client does. + Both start with a version line to indicate which protocol they + have chosen (or an error line if it supports no version in common + with tor), then it lists a number of SMETHOD lines. + Each SMETHOD line is of the form: - [so, we can have this work like client proxies, where the bridge - launches some programs, and they tell the bridge, "I am giving you - method X with parameters Y"? Do you have to take all the methods? If - not, which do you specify?] + SMETHOD: methodname address:port ARGS:k=v,k=v,k=v [Options] - [Do we allow programs that get started independently?] + Or: - [We'll need to figure out how this works with port forwarding. Is - port forwarding the bridge's problem, the proxy's problem, or some - combination of the two?] + SMETHOD-ERROR: methodname message - [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 bridgedb - "don't give out a default bridge line for me"] + SMETHOD and CMETHOD lines may be interspersed. -Server behavior + After the list SMETHOD line, the proxy says "SMETHODS: DONE" + + Each SMETHOD lime is a configured and working server method. + + The 'address:port' part of an SMETHOD line is the address to put + in the bridge line. The ARGS: part is a list of key-value pairs + that the client needs to know. The Options part is a list of + space-separated K:V flags that Tor should know about. Recognized + options are: + + - FORWARD:1 + + If this option is set, and address:port is not a publicly + accessible address, then the bridge needs to forward some + other address:port to address:port via upnp-helper. + + - DECLARE:K=V,... + + If this option is set, all the K=V options should be + added as extension entries to the router descriptor. (See + below) + + Server transports may need to connect to the bridge and pass + additional information about client connections that the bridge would + ordinarily receive from . To to this, they connect to the + "extended server port" as given in SERVER_PORT, sent a short amount of + information, wait for a response, and then send the user traffic + on that port. + + The extended server port protocol is as follows: + + COMMAND [2 bytes, big-endian] + BODYLEN [2 bytes, big-endian] + BODY [Bodylen bytes] + + Commands sent from the transport to the server are: + + [0x0000] DONE: There is no more information to give. (body ignored) + + [0x0001] USERADDR: an address:port string that represents the user's + address. If the transport doesn't actually do addresses, + this shouldn't besent. + + Replies sent from tor to the proxy are: + + [0x1001] OKAY: Send the user's traffic. (body ignored) + + [0x1002] DENY: Tor would prefer not to get more traffic from + this address for a while. (body ignored) + + [We could also use an out-of-band signalling method to tell Tor + about client addresses, but that's a historically error-prone way + to go about annotating connections.] + +Advertising bridge methods: + + Bridges put the 'method' lines in their extra-info documents. + + method SP methodname SP address:port SP arglist NL + + The address:port parse are as returned from an SMETHOD line. The + arglist is a K=V,... list as retuned in the ARGS part of the + SMETHOD line. + + If the SMETHOD line includes a DECLARE: part, the routerinfo gets + a new line: + + method-info SP methodname SP arglist NL Bridge authority behavior + We need to specify a way to test different transport methods that + bridges claim to support. We should test as many as possible. We + should NOT require that we have a way to tra + +Bridgedb behavior: + + Bridgedb can, given a set of router descriptors and their + corresponding extrainfo documents, generate a set of bridge lines + for each descriptor. Bridgedb may want to avoid handing out + methods that seem to get bridges blocked quickly. + Implementation plan - Turn this into a draft proposal + First, we should implement per-bridge socks settings (as + described above in "manually configuring a client proxy for a + bridge") and the extended-server-port mechanism. This will let + bridges run transport proxies such that they can hand-generate + bridge lines to give to clients for testing. Once that's done, + the next most important part seems to be getting the client-side + automatic part written. And once that's done, we can evaluate how + much of the server side is easy for people to do and how much is + hard. + + The "obfsproxy" obfuscating proxy is a likely candidate for an + initial transport, as is Steven Murdoch's http thing or something + similar. - Circulate and discuss on or-dev. +Notes on plugins to write: We should ship a couple of null plugin implementations in one or two popular, portable languages so that people get an idea of how to @@ -262,7 +454,7 @@ Implementation plan 2. We should implement a basic proxy that does not transform the bytes at all - 1. We should implement DNS or HTTP using other software (as goodell + 1. We should implement DNS or HTTP using other software (as goodesll did years ago with DNS) as an example of wrapping existing code into our plugin model. @@ -295,8 +487,6 @@ Appendix: recommendations for transports 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 [XXX] - Avoid security-through-obscurity if possible. Specify. Resist trivial fingerprinting: There should be no good string or regex @@ -307,8 +497,5 @@ Appendix: recommendations for transports protocols -- and in many cases, most possible variants of a given protocol won't actually exist in the wild. -Appendix: Raw-traffic transports - This section describes an optional extension to the proposal above. - We are not sure whether it is a good idea.

1 0

[tor/maint-0.2.2] Fix log message when we have too few dirauths
by arma＠torproject.org 12 Mar '11

12 Mar '11

commit 2f8e96b5535481e157486944c8d7637f31e1a197 Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Mon Mar 7 00:03:09 2011 +0100 Fix log message when we have too few dirauths The calculation of when to send the logmessage was correct, but we didn't give the correct number of relays required: We want more than half of all authorities we know about. Fixes bug 2663. --- src/or/dirvote.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/or/dirvote.c b/src/or/dirvote.c index 529b45c..9273dbc 100644 --- a/src/or/dirvote.c +++ b/src/or/dirvote.c @@ -3080,7 +3080,7 @@ dirvote_compute_consensuses(void) n_votes = smartlist_len(pending_vote_list); if (n_votes <= n_voters/2) { log_warn(LD_DIR, "We don't have enough votes to generate a consensus: " - "%d of %d", n_votes, n_voters/2); + "%d of %d", n_votes, n_voters/2+1); goto err; } tor_assert(pending_vote_list);

1 0

[tor/maint-0.2.2] Merge commit 'sebastian/bug2663' into maint-0.2.2
by arma＠torproject.org 12 Mar '11

12 Mar '11

commit 600ad7bf8d499d04259586bcf91afed7dfb88f99 Merge: 879f171 2f8e96b Author: Roger Dingledine <arma(a)torproject.org> Date: Fri Mar 11 20:37:21 2011 -0500 Merge commit 'sebastian/bug2663' into maint-0.2.2 src/or/dirvote.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)

1 0

r24344: {website} disable arabic man page so we can build arabic again (website/trunk/docs/ar)
by Roger Dingledine 11 Mar '11

11 Mar '11

Author: arma Date: 2011-03-11 23:55:54 +0000 (Fri, 11 Mar 2011) New Revision: 24344 Modified: website/trunk/docs/ar/tor-manual-dev.wml Log: disable arabic man page so we can build arabic again Modified: website/trunk/docs/ar/tor-manual-dev.wml =================================================================== --- website/trunk/docs/ar/tor-manual-dev.wml 2011-03-11 23:54:33 UTC (rev 24343) +++ website/trunk/docs/ar/tor-manual-dev.wml 2011-03-11 23:55:54 UTC (rev 24344) @@ -14,9 +14,9 @@ <div id="maincol"> <: die "Missing git clone" unless -d "$(TORGIT)"; - my $man = `cat manpages/ar/tor.1.txt | asciidoc -d manpage -s -o - -`; - die "No manpage because of asciidoc error or file not available from git" unless $man; - print $man; +# my $man = `cat manpages/ar/tor.1.txt | asciidoc -d manpage -s -o - -`; +# die "No manpage because of asciidoc error or file not available from git" unless $man; +# print $man; :> </div>

1 0

r24343: {website} betcha didn't know we had a new stable release a few weeks a (website/trunk/en)
by Roger Dingledine 11 Mar '11

11 Mar '11

Author: arma Date: 2011-03-11 23:54:33 +0000 (Fri, 11 Mar 2011) New Revision: 24343 Modified: website/trunk/en/index.wml Log: betcha didn't know we had a new stable release a few weeks ago Modified: website/trunk/en/index.wml =================================================================== --- website/trunk/en/index.wml 2011-03-11 23:51:56 UTC (rev 24342) +++ website/trunk/en/index.wml 2011-03-11 23:54:33 UTC (rev 24343) @@ -125,6 +125,16 @@ <table> <tr> <td> + <div class="calendar"><span class="month">Feb</span><br><span class="day">23</span></div> + <p>The latest stable Tor version, 0.2.1.30, is <a + href="https://lists.torproject.org/pipermail/tor-announce/2011-February/000000.ht…">released</a>. + Tor 0.2.1.30 fixes a variety of less critical bugs. The + main other change is a slight tweak to Tor's TLS handshake + that makes relays and bridges that run this new version + reachable from Iran again. We don't expect this tweak + will win the arms race long-term, but it buys us time + until we roll out a better solution. + </p> <div class="calendar"><span class="month">Jan</span><br><span class="day">30</span></div> <p>Tor helping with Egypt. Here's what we've learned <a href="https://blog.torproject.org/blog/recent-events-egypt">about @@ -132,16 +142,6 @@ href="<page press/inthemedia>">In the media</a> page up to date with stories about how we're helping around the world.</p> - <div class="calendar"><span class="month">Jan</span><br><span class="day">17</span></div> - <p>The latest stable Tor version, 0.2.1.29, is <a - href="http://archives.seul.org/or/announce/Jan-2011/msg00000.html">released</a>. - Tor 0.2.1.29 continues our recent code security audit - work. The main fix resolves a remote heap overflow - vulnerability that can allow remote code execution. Other - fixes address a variety of assert and crash bugs, - most of which we think are hard to exploit remotely. - All Tor users should upgrade. - </p> </td> </tr> </table>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits