tor-commits March 2013

tor-commits@lists.torproject.org

21 participants
1373 discussions

[tor/master] Changes file for bug6572.
by nickm＠torproject.org 28 Mar '13

28 Mar '13

commit fc9a72c6886c83f96f0b322dab92dbc3c5a8f26b Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Mar 26 20:29:41 2013 -0700 Changes file for bug6572. --- changes/bug6572 | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/changes/bug6572 b/changes/bug6572 new file mode 100644 index 0000000..6508d1b --- /dev/null +++ b/changes/bug6572 @@ -0,0 +1,4 @@ + o Minor bugfixes (log messages) + - Use circuit creation time for network liveness evaluation. This + should eliminate warning log messages about liveness caused by + changes in timeout evaluation. Fixes bug 6572; bugfix on 0.2.4.8-alpha.

1 0

[tor/master] Clarify liveness log message and lower it to notice.
by nickm＠torproject.org 28 Mar '13

28 Mar '13

commit 87d50d0617d89290ca263aa6f415e45a0c37a11a Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Wed Mar 27 16:22:43 2013 -0700 Clarify liveness log message and lower it to notice. It could just be due to small clock jumps, after all. --- src/or/circuitstats.c | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/or/circuitstats.c b/src/or/circuitstats.c index fe9c80d..1d7812b 100644 --- a/src/or/circuitstats.c +++ b/src/or/circuitstats.c @@ -1232,11 +1232,11 @@ circuit_build_times_network_close(circuit_build_times_t *cbt, format_local_iso_time(last_live_buf, cbt->liveness.network_last_live); format_local_iso_time(start_time_buf, start_time); format_local_iso_time(now_buf, now); - log_warn(LD_BUG, - "Circuit somehow completed a hop while the network was " - "not live. Network was last live at %s, but circuit launched " - "at %s. It's now %s.", last_live_buf, start_time_buf, - now_buf); + log_notice(LD_CIRC, + "A circuit somehow completed a hop while the network was " + "not live. The network was last live at %s, but the circuit " + "launched at %s. It's now %s. This could mean your clock " + "changed.", last_live_buf, start_time_buf, now_buf); } cbt->liveness.nonlive_timeouts++; if (cbt->liveness.nonlive_timeouts == 1) {

1 0

[tor/master] Merge remote-tracking branch 'origin/maint-0.2.4'
by nickm＠torproject.org 28 Mar '13

28 Mar '13

commit eb9b282cc24da6ff1e776ea02f94571e3e3f7017 Merge: e62b805 7f8098d Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Mar 27 21:07:36 2013 -0400 Merge remote-tracking branch 'origin/maint-0.2.4' changes/bug6572 | 4 ++++ changes/bug8598 | 6 ++++++ src/or/circuitbuild.c | 3 +++ src/or/circuitstats.c | 10 +++++----- src/or/circuituse.c | 2 +- 5 files changed, 19 insertions(+), 6 deletions(-)

1 0

[tor/master] Add some missing case values to please clang
by nickm＠torproject.org 28 Mar '13

28 Mar '13

commit 7f8098d2d0e719f3ea9e35a7f930477f8fc7682a Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Mar 27 21:04:08 2013 -0400 Add some missing case values to please clang It seems that some versions of clang that would prefer the -Wswitch-enum compiler flag to warn about switch statements with missing enum values, even if those switch statements have a default. Fixes bug 8598; bugfix on 0.2.4.10-alpha. --- changes/bug8598 | 6 ++++++ src/or/circuitbuild.c | 3 +++ 2 files changed, 9 insertions(+), 0 deletions(-) diff --git a/changes/bug8598 b/changes/bug8598 new file mode 100644 index 0000000..e31c8f3 --- /dev/null +++ b/changes/bug8598 @@ -0,0 +1,6 @@ + o Bugfixes: + - Fix compilation warning with some versions of clang that would prefer + the -Wswitch-enum compiler flag to warn about switch statements with + missing enum values, even if those switch statements have a default: + statement. Fixes bug 8598; bugfix on 0.2.4.10-alpha. + diff --git a/src/or/circuitbuild.c b/src/or/circuitbuild.c index ce552b4..aec6c6a 100644 --- a/src/or/circuitbuild.c +++ b/src/or/circuitbuild.c @@ -2010,6 +2010,9 @@ pathbias_check_close(origin_circuit_t *ocirc, int reason) pathbias_count_use_failed(ocirc); break; + case PATH_STATE_NEW_CIRC: + case PATH_STATE_BUILD_ATTEMPTED: + case PATH_STATE_ALREADY_COUNTED: default: // Other states are uninteresting. No stats to count. break;

1 0

[tor/maint-0.2.4] Add some missing case values to please clang
by nickm＠torproject.org 28 Mar '13

28 Mar '13

1 0

[tor/maint-0.2.4] Changes file for bug6572.
by nickm＠torproject.org 28 Mar '13

28 Mar '13

1 0

[tor/maint-0.2.4] Clarify liveness log message and lower it to notice.
by nickm＠torproject.org 28 Mar '13

28 Mar '13

1 0

[tor/maint-0.2.4] Bug 6572: Use timestamp_created for liveness sanity checks.
by nickm＠torproject.org 28 Mar '13

28 Mar '13

commit 65c0489dd4f0e10230f5c2fbb772a58e03e939bb Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Mar 26 20:28:19 2013 -0700 Bug 6572: Use timestamp_created for liveness sanity checks. This should eliminate potential regressions caused by #7341. --- src/or/circuituse.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/or/circuituse.c b/src/or/circuituse.c index f02597e..14576f1 100644 --- a/src/or/circuituse.c +++ b/src/or/circuituse.c @@ -671,7 +671,7 @@ circuit_expire_building(void) circuit_purpose_to_string(victim->purpose)); } else if (circuit_build_times_count_close(&circ_times, first_hop_succeeded, - victim->timestamp_began.tv_sec)) { + victim->timestamp_created.tv_sec)) { circuit_build_times_set_timeout(&circ_times); } }

1 0

[torspec/master] Initial draft of path bias spec updates.
by nickm＠torproject.org 28 Mar '13

28 Mar '13

commit 5d5742d68e439dfcb849892de1ca6059c857dc1d Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Mon Mar 25 21:45:41 2013 -0700 Initial draft of path bias spec updates. Still needs parameter description. --- path-spec.txt | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 108 insertions(+), 1 deletions(-) diff --git a/path-spec.txt b/path-spec.txt index 7d19889..ee6aa5f 100644 --- a/path-spec.txt +++ b/path-spec.txt @@ -512,7 +512,8 @@ of their choices. so we treat the exit node as if it were a non-exit until we retrieve a fresh descriptor for it. - XXXX + Excessive amounts of either type of failure can indicate an + attack on anonymity. See section 7 for how excessive failure is handled. 3. Attaching streams to circuits @@ -604,6 +605,112 @@ of their choices. 125 for specific details. Currently bridge descriptors are used in place of normal entry guards, for Tor clients that have UseBridges enabled. +7. Detecting route manipulation by Guard nodes (Path Bias) + + The Path Bias defense is designed to defend against a type of route + capture where malicious Guard nodes deliberately fail or choke circuits + that extend to non-colluding Exit nodes to maximize their network + utilization in favor of carrying only compromised traffic. + + In the extreme, the attack allows an adversary that carries c/n + of the network capacity to deanonymize c/n of the network + connections, breaking the O((c/n)^2) property of Tor's original + threat model. + + There are two points where path selection can be manipulated: + during construction, and during usage. Circuit construction + can be manipulated by inducing circuit failures during circuit + extend steps, which causes the Tor client to transparently retry + the circuit construction with a new path. Circuit usage can be + manipulated by abusing the stream retry features of Tor (for + example by withholding stream attempt responses from the client + until the stream timeout has expired), at which point the tor client + will also transparently retry the stream on a new path. + + The defense as deployed therefore makes two independent sets of + measurements of successful path use: one during construction, and + one during usage. + + The intended behavior is for clients to ultimately disable the use + of Guards responsible for excessive circuit failure of either type + (see section 7.4); however known issues with the Tor network currently + restrict the defense to being informational only at this stage (see + section 7.5). + +7.1. Measuring path construction success rates + + Clients maintain two counts for each of their guards: a count of the + number of times a circuit was extended to at least two hops through that + guard, and a count of the number of circuits that successfully complete + through that guard. The ratio of these two numbers is used to determine + a circuit success rate for that Guard. + + Circuit build timeouts are counted as construction failures if the + circuit fails to complete before the 95% "right-censored" timeout + interval, not the 80% timeout condition (see section 2.4). + + If a circuit closes prematurely after construction but before being + requested to close by the client, this is counted as a failure. + +7.2. Measuring path usage success rates + + Clients maintain two usage counts for each of their guards: a count + of the number of usage attempts, and a count of the number of + successful usages. + + A usage attempt means any attempt to attach a stream to a circuit. + + Usage success status is temporarily recorded by state flags on circuits. + Guard usage success counts are not incremented until circuit close. A + circuit is marked as successfully used if we receive a properly + recognized RELAY cell on that circuit that was expected for the current + circuit purpose. + + If subsequent stream attachments fail or time out, the successfully used + state of the circuit is cleared, causing it once again to be regarded + as a usage attempt only. + + Upon close by the client, all circuits that are still marked as usage + attempts are probed using a RELAY_BEGIN cell constructed with a + destination of the form 0.a.b.c:25, where a.b.c is a 24 bit random + nonce. If we get a RELAY_COMMAND_END in response matching our nonce, + the circuit is counted as successfully used. + + If any unrecognized RELAY cells arrive after the probe has been sent, + the circuit is counted as a usage failure. + + If the stream failure reason codes DESTROY, TORPROTOCOL, or INTERNAL + are received in response to any stream attempt, such circuits are not + probed and are declared usage failures. + + Prematurely closed circuits are not probed, and are counted as usage + failures. + +7.3. Scaling success counts + + To provide a moving average of recent Guard activity while + still preserving the ability to verify correctness, we periodically + "scale" the success counts by multiplying them by a scale factor + between 0 and 1.0. + + Scaling is performed when either usage or construction attempt counts + exceed a parametrized value. + + To avoid error due to scaling during circuit construction and use, + currently open circuits are subtracted from the usage counts before + scaling, and added back after scaling. + +7.4. Parametrization + +7.5. Known barriers to enforcement + + Due to intermittent CPU overload at relays, the normal rate of + successful circuit completion is highly variable. The Guard-dropping + version of the defense is unlikely to be deployed until the ntor + circuit handshake is enabled, or the nature of CPU overload induced + failure is better understood. + + X. Old notes

1 0

[torspec/master] Describe path bias consensus parameters and clarify some wording.
by nickm＠torproject.org 28 Mar '13

28 Mar '13

commit 5d42cd782a0416fc421c5822d7bc56eb955b975b Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Wed Mar 27 17:05:40 2013 -0700 Describe path bias consensus parameters and clarify some wording. --- path-spec.txt | 87 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 files changed, 84 insertions(+), 3 deletions(-) diff --git a/path-spec.txt b/path-spec.txt index ee6aa5f..f4fc6c5 100644 --- a/path-spec.txt +++ b/path-spec.txt @@ -615,7 +615,8 @@ of their choices. In the extreme, the attack allows an adversary that carries c/n of the network capacity to deanonymize c/n of the network connections, breaking the O((c/n)^2) property of Tor's original - threat model. + threat model. It also allows targeted attacks aimed at monitoring + the activity of specific users, bridges, or Guard nodes. There are two points where path selection can be manipulated: during construction, and during usage. Circuit construction @@ -628,8 +629,8 @@ of their choices. will also transparently retry the stream on a new path. The defense as deployed therefore makes two independent sets of - measurements of successful path use: one during construction, and - one during usage. + measurements of successful path use: one during circuit construction, + and one during circuit usage. The intended behavior is for clients to ultimately disable the use of Guards responsible for excessive circuit failure of either type @@ -702,6 +703,86 @@ of their choices. 7.4. Parametrization + The following consensus parameters tune various aspects of the + defense. + + pb_mincircs + Default: 150 + Min: 5 + Effect: This is the minimum number of circuits that must complete + at least 2 hops before we begin evaluating construction rates. + + + pb_noticepct + Default: 70 + Min: 0 + Max: 100 + Effect: If the circuit success rate falls below this percentage, + we emit a notice log message. + + pb_warnpct + Default: 50 + Min: 0 + Max: 100 + Effect: If the circuit success rate falls below this percentage, + we emit a warn log message. + + pb_extremepct + Default: 30 + Min: 0 + Max: 100 + Effect: If the circuit success rate falls below this percentage, + we emit a more alarmist warning log message. If + pb_dropguard is set to 1, we also disable the use of the + guard. + + pb_dropguards + Default: 0 + Min: 0 + Max: 1 + Effect: If the circuit success rate falls below pb_extremepct, + when pb_dropguard is set to 1, we disable use of that + guard. + + pb_scalecircs + Default: 300 + Min: 10 + Effect: After this many circuits have completed at least two hops, + Tor performs the scaling described in Section 7.3. + + pb_multfactor and pb_scalefactor + Default: 1/2 + Min: 0.0 + Max: 1.0 + Effect: The double-precision result obtained from + pb_multfactor/pb_scalefactor is multiplied by our current + counts to scale them. + + pb_minuse + Default: 20 + Min: 3 + Effect: This is the minimum number of circuits that we must attempt to + use before we begin evaluating construction rates. + + pb_noticeusepct + Default: 80 + Min: 3 + Effect: If the circuit usage success rate falls below this percentage, + we emit a notice log message. + + pb_extremeusepct + Default: 60 + Min: 3 + Effect: If the circuit usage success rate falls below this percentage, + we emit a warning log message. We also disable the use of the + guard if pb_dropguards is set. + + pb_scaleuse + Default: 100 + Min: 10 + Effect: After we have attempted to use this many circuits, + Tor performs the scaling described in Section 7.3. + 7.5. Known barriers to enforcement Due to intermittent CPU overload at relays, the normal rate of

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits March 2013