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

[tor/master] entry_guard_pick_for_circuit(): TRAFFIC guards must have descriptors
by nickm＠torproject.org 01 Feb '17

01 Feb '17

commit 26957a127a80404ca243e50c3f0c2bac01e480b8 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Jan 31 11:46:06 2017 -0500 entry_guard_pick_for_circuit(): TRAFFIC guards must have descriptors This relates to the 21242 fix -- entry_guard_pick_for_circuit() should never yield nodes without descriptors when the node is going to be used for traffic, since we won't be able to extend through them. --- src/or/entrynodes.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/or/entrynodes.c b/src/or/entrynodes.c index c5fb92e..344b69d 100644 --- a/src/or/entrynodes.c +++ b/src/or/entrynodes.c @@ -2068,6 +2068,8 @@ entry_guard_pick_for_circuit(guard_selection_t *gs, // XXXX prop271 check Ed ID. if (! node) goto fail; + if (BUG(usage != GUARD_USAGE_DIRGUARD && !node_has_descriptor(node))) + goto fail; *chosen_node_out = node; *guard_state_out = tor_malloc_zero(sizeof(circuit_guard_state_t));

1 0

[torspec/master] Merge branch 'feature21242'
by nickm＠torproject.org 01 Feb '17

01 Feb '17

commit 7cbcbf5bcbac29d0f2acb6c65ea2c5eb12937ea0 Merge: ee2a7f8 b729833 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Feb 1 09:15:33 2017 -0500 Merge branch 'feature21242' guard-spec.txt | 22 ++++++++++++++++++++-- path-spec.txt | 33 +++++++++++++++++++++++++++++++++ 2 files changed, 53 insertions(+), 2 deletions(-)

1 0

[torspec/master] Explain more about primary guards and about building circuits
by nickm＠torproject.org 01 Feb '17

01 Feb '17

commit b729833befc66d94ce0510356290586e43402dee Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Feb 1 08:54:07 2017 -0500 Explain more about primary guards and about building circuits In path-spec: explain our rules (post-21242) for waiting to build circuits. In guard-spec: - explain what to do about missing descriptors - explain parallel use of multiple primary guards, based on parameters. --- guard-spec.txt | 22 ++++++++++++++++++++-- path-spec.txt | 33 +++++++++++++++++++++++++++++++++ 2 files changed, 53 insertions(+), 2 deletions(-) diff --git a/guard-spec.txt b/guard-spec.txt index 59c66b8..87e16a7 100644 --- a/guard-spec.txt +++ b/guard-spec.txt @@ -451,8 +451,10 @@ When we want to build a circuit, and we need to pick a guard: * If any entry in PRIMARY_GUARDS has {is_reachable} status of - <maybe> or <yes>, return the first such guard. The circuit is - <usable_on_completion>. + <maybe> or <yes>, return one of the first + {NUM_USABLE_PRIMARY_GUARDS} or + {NUM_USABLE_PRIMARY_DIRECTORY_GUARDS} such guards, chosen + uniformly at random. The circuit is <usable_on_completion>. [Note: We do not use {is_pending} on primary guards, since we are willing to try to build multiple circuits through them @@ -620,6 +622,18 @@ circuits are neither built nor in-progress; that <complete> circuits are built; and that the other states are in-progress. +4.12. When we are missing descriptors + [Section:MISSING_DESCRIPTORS] + + We need either a router descriptor or a microdescriptor in order + to build a circuit through a guard. If we do not have such a + descriptor for a guard, we can still use the guard for one-hop + directory fetches, but not for longer circuits. + + (Also, when we are missing descriptors for our first + {NUM_USABLE_PRIMARY_GUARDS} primary guards, we don't build + circuits at all until we have fetched them.) + A. Appendices A.1. Parameters with suggested values. [Section:PARAM_VALS] @@ -663,6 +677,10 @@ A.1. Parameters with suggested values. [Section:PARAM_VALS] {param:GUARD_CONFIRMED_MIN_LIFETIME} -- 60 days + {param:NUM_USABLE_PRIMARY_GUARDS} -- 1 + + {param:NUM_USABLE_PRIMARY_DIRECTORY_GUARDS} -- 3 + A.2. Random values [Section:RANDOM] Frequently, we want to randomize the expiration time of something diff --git a/path-spec.txt b/path-spec.txt index ceb6c77..6e88cb3 100644 --- a/path-spec.txt +++ b/path-spec.txt @@ -112,6 +112,39 @@ of their choices. 2.1. When we build +2.1.0. We don't build circuits until we have enough directory info + + There's a class of possible attacks where our directory servers + only give us information about the relays that they would like us + to use. To prevent this attack, we don't build multi-hop + circuits for real traffic (like those in 2.1.1, 2.1.2, 2.1.4 + below) until we have enough directory information to be + reasonably confident this attack isn't being done to us. + + Here, "enough" directory information is defined as: + + * Having a consensus that's been valid at some point in the + last REASONABLY_LIVE_TIME interval (24 hourts). + + * Having enough descriptors that we could build at least some + fraction F of all bandwidth-weighted paths, without taking + ExitNodes/EntryNodes/etc into account. + + (F is set by the PathsNeededToBuildCircuits option, + defaulting to the 'min_paths_for_circs_pct' consensus + parameter, with a final default value of 60%.) + + * Having enough descriptors that we could build at least some + fraction F of all bandwidth-weighted paths, _while_ taking + ExitNodes/EntryNodes/etc into account. + + (F is as above.) + + * Having a descriptor for every one of the first + NUM_GUARDS_TO_USE guards among our primary guards. (see + guard-spec.txt) + + 2.1.1. Clients build circuits preemptively When running as a client, Tor tries to maintain at least a certain

1 0

[tor/master] Don't try to use confirmed_idx in remove_guard_from_...lists()
by nickm＠torproject.org 01 Feb '17

01 Feb '17

commit 0f0d4356b21df48f1832c3de606eb70e16e94566 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Jan 31 14:34:32 2017 -0500 Don't try to use confirmed_idx in remove_guard_from_...lists() Since we can call this function more than once before we update all the confirmed_idx fields, we can't rely on all the relays having an accurate confirmed_idx. Fixes bug 21129; bugfix on 0.3.0.1-alpha --- changes/bug21129 | 4 ++++ src/or/entrynodes.c | 13 +------------ 2 files changed, 5 insertions(+), 12 deletions(-) diff --git a/changes/bug21129 b/changes/bug21129 new file mode 100644 index 0000000..5a09bb4 --- /dev/null +++ b/changes/bug21129 @@ -0,0 +1,4 @@ + o Minor bugfixes (client, entry guards): + - Fix a spurious bug warning (with backtrace) when removing an + expired entry guard. Fixes bug 21129; bugfix on 0.3.0.1-alpha. + diff --git a/src/or/entrynodes.c b/src/or/entrynodes.c index c5fb92e..30a1f4b 100644 --- a/src/or/entrynodes.c +++ b/src/or/entrynodes.c @@ -1112,18 +1112,7 @@ remove_guard_from_confirmed_and_primary_lists(guard_selection_t *gs, } if (guard->confirmed_idx >= 0) { - entry_guard_t *found_guard = NULL; - if (guard->confirmed_idx < smartlist_len(gs->confirmed_entry_guards)) - found_guard = smartlist_get(gs->confirmed_entry_guards, - guard->confirmed_idx); - if (BUG(guard != found_guard)) { - // LCOV_EXCL_START - smartlist_remove_keeporder(gs->confirmed_entry_guards, guard); - // LCOV_EXCL_STOP - } else { - smartlist_del_keeporder(gs->confirmed_entry_guards, - guard->confirmed_idx); - } + smartlist_remove_keeporder(gs->confirmed_entry_guards, guard); guard->confirmed_idx = -1; guard->confirmed_on_date = 0; } else {

1 0

[tor/master] When marking guard state instances on a channel, don't mark NULL
by nickm＠torproject.org 01 Feb '17

01 Feb '17

commit 35d827094237e92436ff28fffeb282ac83220839 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Jan 31 14:44:14 2017 -0500 When marking guard state instances on a channel, don't mark NULL It's okay for guard_state to be null: we might have a fallback circuit, or we might not be using guards. Fixes bug 211228; bugfix on 0.3.0.1-alpha --- changes/bug21128 | 5 +++++ src/or/entrynodes.c | 6 +++++- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/changes/bug21128 b/changes/bug21128 new file mode 100644 index 0000000..972d2a2 --- /dev/null +++ b/changes/bug21128 @@ -0,0 +1,5 @@ + o Minor bugfixes (client, entry guards): + - Fix a bug warning (with backtrace) when we fail a channel + that circuits to fallback directories on it. Fixes bug 21128; + bugfix on 0.3.0.1-alpha. + diff --git a/src/or/entrynodes.c b/src/or/entrynodes.c index c5fb92e..f9b3b60 100644 --- a/src/or/entrynodes.c +++ b/src/or/entrynodes.c @@ -2172,7 +2172,11 @@ entry_guard_chan_failed(channel_t *chan) continue; origin_circuit_t *origin_circ = TO_ORIGIN_CIRCUIT(circ); - entry_guard_failed(&origin_circ->guard_state); + if (origin_circ->guard_state) { + /* We might have no guard state if we didn't use a guard on this + * circuit (eg it's for a fallback directory). */ + entry_guard_failed(&origin_circ->guard_state); + } } SMARTLIST_FOREACH_END(circ); smartlist_free(pending); }

1 0

[tor/master] Merge remote-tracking branch 'public/bug21128'
by nickm＠torproject.org 01 Feb '17

01 Feb '17

commit f8885b76ef353c4bccc90119448df5301b3ba8cb Merge: a5aec6a 35d8270 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Feb 1 09:01:28 2017 -0500 Merge remote-tracking branch 'public/bug21128' changes/bug21128 | 5 +++++ src/or/entrynodes.c | 6 +++++- 2 files changed, 10 insertions(+), 1 deletion(-)

1 0

[tor/master] Merge remote-tracking branch 'public/bug21129'
by nickm＠torproject.org 01 Feb '17

01 Feb '17

commit 2e93bffa1dbd4e38038a040b1159ade093cdf41c Merge: f8885b7 0f0d435 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Feb 1 09:01:44 2017 -0500 Merge remote-tracking branch 'public/bug21129' changes/bug21129 | 4 ++++ src/or/entrynodes.c | 13 +------------ 2 files changed, 5 insertions(+), 12 deletions(-)

1 0

[torspec/master] Merge branch 'bug16852_more'
by nickm＠torproject.org 01 Feb '17

01 Feb '17

commit ee2a7f89fe1b9ce824f38f8bdb0f911d7938bfc8 Merge: 717fa8a 94f6baa Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Feb 1 08:15:15 2017 -0500 Merge branch 'bug16852_more' dir-spec.txt | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)

1 0

[torspec/master] Describe better how we vote for the guard flag.
by nickm＠torproject.org 01 Feb '17

01 Feb '17

commit 94f6baabad4953bbf1e4851972d9d4dc45398d56 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Jan 31 13:53:04 2017 -0500 Describe better how we vote for the guard flag. Closes 16852. --- dir-spec.txt | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index 0650074..d91f76f 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -2299,9 +2299,14 @@ "Fast" -- A router is 'Fast' if it is active, and its bandwidth is either in the top 7/8ths for known active routers or at least 100KB/s. - "Guard" -- A router is a possible 'Guard' if its Weighted Fractional Uptime - is at least the median for "familiar" active routers, and if its bandwidth - is at least 2MB/s or is in the set of the 25% fastest relays. + "Guard" -- A router is a possible Guard if all of the following apply: + - It is Fast. + - It is Stable. + - Its Weighted Fractional Uptime is at least the median for "familiar" + active routers, + - It is "familiar", + - Its bandwidth is at least AuthDirGuardBWGuarantee (if set, 2 MB by + default), OR its bandwidth is among the 25% fastest relays. To calculate weighted fractional uptime, compute the fraction of time that the router is up in any given day, weighting so that

1 0

[torspec/master] prop224: Clarify how checksum truncation works.
by asn＠torproject.org 01 Feb '17

01 Feb '17

commit 717fa8a4560d876f0144d82914fc4fb4ce3e9c30 Author: George Kadianakis <desnacked(a)riseup.net> Date: Wed Feb 1 14:36:48 2017 +0200 prop224: Clarify how checksum truncation works. --- proposals/224-rend-spec-ng.txt | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 6f71b32..69cd7c6 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -1875,7 +1875,7 @@ Table of contents: encoded as shown below: onion_address = base32(PUBKEY || CHECKSUM || VERSION) + ".onion" - CHECKSUM = H(".onion checksum" || PUBKEY || VERSION) + CHECKSUM = H(".onion checksum" || PUBKEY || VERSION)[:2] where: - PUBKEY is the 32 bytes ed25519 master pubkey of the hidden service. @@ -1883,11 +1883,11 @@ Table of contents: - ".onion checksum" is a constant string - CHECKSUM is truncated to two bytes before inserting it in onion_address - Here are a few example addresses (with broken checksum): + Here are a few example addresses: - l5satjgud6gucryazcyvyvhuxhr74u6ygigiuyixe3a6ysis67ororad.onion - btojiu7nu5y5iwut64eufevogqdw4wmqzugnoluw232r4t3ecsfv37ad.onion - vckjr6bpchiahzhmtzslnl477hdfvwhzw7dmymz3s5lp64mwf6wfeqad.onion + pg6mmjiyjmcrsslvykfwnntlaru7p5svn6y2ymmju6nubxndf4pscryd.onion + sp3k262uwy4r2k3ycr5awluarykdpag6a7y33jxop4cs2lu5uz5sseqd.onion + xa4r2iadxm55fbnqgwwi5mymqdcofiu3w6rpbtqn7b2dyn7mgwj64jyd.onion For more information about this encoding, please see our discussion thread at [ONIONADDRESS-REFS].

1 0