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

[torspec/master] prop224: Clarify time period example
by nickm＠torproject.org 18 Jan '17

18 Jan '17

commit 09d71e45814505d004c10c7bc156d576c6a59956 Author: Nicolas Braud-Santoni <nicolas(a)braud-santoni.eu> Date: Sat Jan 14 16:12:17 2017 +0100 prop224: Clarify time period example It was unclear whether this was “the epoch at <time>” or “(X seconds after the epoch) at <time>”. --- proposals/224-rend-spec-ng.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 53a1479..72093b3 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -723,8 +723,8 @@ Table of contents: in time period number 16903. Specifically, time period #16903 began 16903*1440*60 + (12*60*60) seconds - after the epoch at 2016-04-12 12:00 UTC, and ended at 16904*1440*60 + - (12*60*60) seconds after the epoch at 2016-04-13 12:00 UTC. + after the epoch, at 2016-04-12 12:00 UTC, and ended at 16904*1440*60 + + (12*60*60) seconds after the epoch, at 2016-04-13 12:00 UTC. 2.2.2. When to publish a hidden service descriptor [WHEN-HSDESC]

1 0

[torspec/master] Merge remote-tracking branch 'nicoo/p224-typo'
by nickm＠torproject.org 18 Jan '17

18 Jan '17

commit 2c2d27861e1d2f33056de6dacd1ac48d8d9bf145 Merge: f45e162 09d71e4 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Jan 18 09:27:56 2017 -0500 Merge remote-tracking branch 'nicoo/p224-typo' proposals/224-rend-spec-ng.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

1 0

[torspec/master] spelling fix
by nickm＠torproject.org 18 Jan '17

18 Jan '17

commit ee6c183d7148214a5096f365b3c32011c5c82bf1 Author: Chelsea H. Komlo <chelsea.komlo(a)gmail.com> Date: Fri Dec 23 12:42:42 2016 -0500 spelling fix --- proposals/271-another-guard-selection.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/271-another-guard-selection.txt b/proposals/271-another-guard-selection.txt index 0e39ea9..404d015 100644 --- a/proposals/271-another-guard-selection.txt +++ b/proposals/271-another-guard-selection.txt @@ -316,7 +316,7 @@ Implemented-In: 0.3.0.1-alpha Definition: we call Guard A "higher priority" than another Guard B if, when A and B are both reachable, we would rather use A. We - define prioirty as follows: + define priority as follows: * Every guard in {CONFIRMED_GUARDS} has a higher priority than every guard not in {CONFIRMED_GUARDS}.

1 0

[torspec/master] Add punctuation fix
by nickm＠torproject.org 18 Jan '17

18 Jan '17

commit 547d1f38d9749038a7fadb7126a4b96e6228172a Author: Chelsea H. Komlo <chelsea.komlo(a)gmail.com> Date: Wed Jan 11 08:24:18 2017 -0500 Add punctuation fix --- proposals/271-another-guard-selection.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/271-another-guard-selection.txt b/proposals/271-another-guard-selection.txt index 82d73d1..b606cc2 100644 --- a/proposals/271-another-guard-selection.txt +++ b/proposals/271-another-guard-selection.txt @@ -203,7 +203,7 @@ Implemented-In: 0.3.0.1-alpha circuits already exist with higher-priority guards. If at any point the circuit fails, the guard is marked as - unreachable, the circuit is closed. and waiting circuits are updated. + unreachable, the circuit is closed, and waiting circuits are updated. 4. The algorithm.

1 0

[torspec/master] Merge remote-tracking branch 'origin/master'
by nickm＠torproject.org 18 Jan '17

18 Jan '17

commit f45e1626c5c6573691a06e3337fd04b5abbcb9be Merge: 32ef2f3 3681931 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Jan 18 09:27:08 2017 -0500 Merge remote-tracking branch 'origin/master' control-spec.txt | 4 ++-- dir-spec.txt | 1 + 2 files changed, 3 insertions(+), 2 deletions(-)

1 0

[torspec/master] Adding high level circuit & guard picking overview
by nickm＠torproject.org 18 Jan '17

18 Jan '17

commit 6b813c4af9290c5a7eda196bda385adb4b780588 Author: Chelsea H. Komlo <chelsea.komlo(a)gmail.com> Date: Fri Dec 23 10:39:22 2016 -0500 Adding high level circuit & guard picking overview Defining useful glossary terms --- glossary.txt | 21 ++++++- proposals/271-another-guard-selection.txt | 96 +++++++++++++++++++++++++------ 2 files changed, 98 insertions(+), 19 deletions(-) diff --git a/glossary.txt b/glossary.txt index 7fcd4fa..ba4baeb 100644 --- a/glossary.txt +++ b/glossary.txt @@ -29,13 +29,30 @@ This glossary is not a design document; it is only a reference. Client, aka OP (onion proxy) Bridge - - Circuit - + + Circuit: An established path through the network, where cryptographic keys + are negotiated using the ntor protocol with each hop. Circuits can differ + in length depending on their purpose. See also Leaky Pipe Topology. + + Origin Circuit - + + Exit Circuit: A circuit which connects clients to destinations + outside the Tor network. For example, if a client wanted to visit + duckduckgo.com, this connection would require an exit circuit. + + Internal Circuit: A circuit whose traffic never leaves the Tor + network. For example, a client could connect to a hidden service via + an internal circuit. + Stream Edge connection: TLS connection: - + Link handshake Circuit handshake + Leaky Pipe Topology: The ability for packets to be addressed to any hop + in the path of a circuit. The destination hop is determined by using the + recognized field of relay cells. diff --git a/proposals/271-another-guard-selection.txt b/proposals/271-another-guard-selection.txt index 404d015..82d73d1 100644 --- a/proposals/271-another-guard-selection.txt +++ b/proposals/271-another-guard-selection.txt @@ -139,9 +139,75 @@ Implemented-In: 0.3.0.1-alpha If neither of the above variant-state instances is used, we use a default instance. -3. The algorithm. +3. Circuit Creation, Entry Guard Selection (1000 foot view) -3.0. The guards listed in the current consensus. [Section:GUARDS] + A circuit in Tor is a path through the network connecting a client to + its destination. At a high-level, a three-hop exit circuit will look + like this: + + Client <-> Entry Guard <-> Middle Node <-> Exit Node <-> Destination + + Entry guards are the only nodes which a client will connect to + directly, Exit relays are the nodes by which traffic exists the + Tor network in order to connect to an external destination. + + 3.1 Path selection + + For any circuit, at least one entry guard and middle node(s) are + required. An exit node is required if traffic will exit the Tor + network. Depending on its configuration, a relay listed in a + consensus could be used for any of these roles. However, this + proposal defines how entry guards specifically should be selected and + managed, as opposed to middle or exit nodes. + + 3.1.1 Entry guard selection + + At a high level, a relay listed in a consensus will move through the + following states in the process from initial selection to eventual + usage as an entry guard: + + relays listed in consensus + | + sampled + | | + confirmed filtered + | | | + primary usable_filtered + + Relays listed in the latest consensus can be sampled for guard usage + if they have the "Guard" flag. Sampling is random but weighted by + bandwidth. + + Once a path is built and a circuit established using this guard, it + is marked as confirmed. Until this point, guards are first sampled + and then filtered based on information such as our current + configuration (see SAMPLED and FILTERED sections) and later marked as + usable_filtered if the guard is not primary but can be reached. + + It is always preferable to use a primary guard when building a new + circuit in order to reduce guard churn; only on failure to connect to + existing primary guards will new guards be used. + + 3.1.2 Middle and exit node selection + + Middle nodes are selected at random from relays listed in the + latest consensus, weighted by bandwidth. Exit nodes are chosen + similarly but restricted to relays with an exit policy. + + 3.2 Circuit Building + + Once a path is chosen, Tor will use this path to build a new circuit. + + If the circuit is built successfully, it either can be used + immediately or wait for a better guard, depending on whether other + circuits already exist with higher-priority guards. + + If at any point the circuit fails, the guard is marked as + unreachable, the circuit is closed. and waiting circuits are updated. + +4. The algorithm. + +4.0. The guards listed in the current consensus. [Section:GUARDS] By {set:GUARDS} we mean the set of all guards in the current consensus that are usable for all circuits and directory @@ -152,7 +218,7 @@ Implemented-In: 0.3.0.1-alpha We require all guards to have the flags that we potentially need from any guard, so that all guards are usable for all circuits. -3.1. The Sampled Guard Set. [Section:SAMPLED] +4.1. The Sampled Guard Set. [Section:SAMPLED] We maintain a set, {set:SAMPLED_GUARDS}, that persists across invocations of Tor. It is an unordered subset of the nodes that @@ -242,7 +308,7 @@ Implemented-In: 0.3.0.1-alpha over time. -3.2. The Usable Sample [Section:FILTERED] +4.2. The Usable Sample [Section:FILTERED] We maintain another set, {set:FILTERED_GUARDS}, that does not persist. It is derived from: @@ -289,7 +355,7 @@ Implemented-In: 0.3.0.1-alpha before the sampling, then our sample would reflect the set of filtering restrictions that we had in the past. -3.3. The confirmed-guard list. [Section:CONFIRMED] +4.3. The confirmed-guard list. [Section:CONFIRMED] [formerly USED_GUARDS] @@ -343,7 +409,7 @@ Implemented-In: 0.3.0.1-alpha committing to a guard before we actually use it for sensitive traffic. -3.4. The Primary guards [Section:PRIMARY] +4.4. The Primary guards [Section:PRIMARY] We keep a run-time non-persistent ordered list of {list:PRIMARY_GUARDS}. It is a subset of {FILTERED_GUARDS}. It @@ -371,7 +437,7 @@ Implemented-In: 0.3.0.1-alpha first double-check whether perhaps one of the primary guards is usable after all. -3.5. Retrying guards. [Section:RETRYING] +4.5. Retrying guards. [Section:RETRYING] (We run this process as frequently as needed. It can be done once a second, or just-in-time.) @@ -392,7 +458,7 @@ Implemented-In: 0.3.0.1-alpha a given amount of time, since we can't infer that it's unreachable now from the fact that it was unreachable a few minutes ago. -3.6. Selecting guards for circuits. [Section:SELECTING] +4.6. Selecting guards for circuits. [Section:SELECTING] Every origin circuit is now in one of these states: <state:usable_on_completion>, @@ -479,7 +545,7 @@ Implemented-In: 0.3.0.1-alpha [XXX timeout.] -3.7. When a circuit fails. [Section:ON_FAIL] +4.7. When a circuit fails. [Section:ON_FAIL] When a circuit fails in a way that makes us conclude that a guard is not reachable, we take the following steps: @@ -501,7 +567,7 @@ Implemented-In: 0.3.0.1-alpha See [SELECTING] above for rationale. -3.8. When a circuit succeeds [Section:ON_SUCCESS] +4.8. When a circuit succeeds [Section:ON_SUCCESS] When a circuit succeeds in a way that makes us conclude that a guard _was_ reachable, we take these steps: @@ -535,7 +601,7 @@ Implemented-In: 0.3.0.1-alpha See [SELECTING] above for rationale. -3.9. Updating the list of waiting circuits [Section:UPDATE_WAITING] +4.9. Updating the list of waiting circuits [Section:UPDATE_WAITING] We run this procedure whenever it's possible that a <waiting_for_better_guard> circuit might be ready to be called @@ -572,7 +638,7 @@ Implemented-In: 0.3.0.1-alpha them after all if the <complete> circuit goes down before {NONPRIMARY_GUARD_IDLE_TIMEOUT} seconds. -3.10. Whenever we get a new consensus. [Section:ON_CONSENSUS] +4.10. Whenever we get a new consensus. [Section:ON_CONSENSUS] We update {GUARDS}. @@ -591,7 +657,7 @@ Implemented-In: 0.3.0.1-alpha filter is updated, we repeat the process above, starting at the [**] line.) -3.11. Deciding whether to generate a new circuit. +4.11. Deciding whether to generate a new circuit. [Section:NEW_CIRCUIT_NEEDED] In current Tor, we generate a new circuit when we don't have @@ -776,10 +842,6 @@ A.4. Persistent state format TODO. Still non-addressed issues [Section:TODO] - - Explain the overall flow of the circuit creation and guard - picking algorithms, if they are not clear. - Simulate to answer: Will this work in a dystopic world? Simulate actual behavior.

1 0

[torspec/master] Merge remote-tracking branch 'chelseakomlo/prop271'
by nickm＠torproject.org 18 Jan '17

18 Jan '17

commit 32ef2f38f2a6674e7502706d8f3e3d0d70c9a5fe Merge: 6602c67 547d1f3 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Jan 16 13:11:22 2017 -0500 Merge remote-tracking branch 'chelseakomlo/prop271' glossary.txt | 21 ++++++- proposals/271-another-guard-selection.txt | 98 +++++++++++++++++++++++++------ 2 files changed, 99 insertions(+), 20 deletions(-)

1 0

[tor/master] Merge remote-tracking branch 'dgoulet/bug21058_030_01'
by nickm＠torproject.org 18 Jan '17

18 Jan '17

commit d31209ad6f65c8a4725bbed3e614b9ccff24eb3f Merge: 69cb6f3 5a83bb0 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Jan 18 09:18:01 2017 -0500 Merge remote-tracking branch 'dgoulet/bug21058_030_01' changes/bug21058 | 3 +++ doc/tor.1.txt | 33 +++++++++++++++++---------------- 2 files changed, 20 insertions(+), 16 deletions(-)

1 0

[tor/master] man: Clarify options in the tor.1 man page
by nickm＠torproject.org 18 Jan '17

18 Jan '17

commit 5a83bb0e90a73b1d2cea96b2a4e79a1ffbd37cac Author: David Goulet <dgoulet(a)torproject.org> Date: Tue Jan 17 15:19:42 2017 -0500 man: Clarify options in the tor.1 man page In addition to the comments in the ticket, couple hidden service options have been improved to clarify the maximum and minimum values they can be set to. Closes #21058 Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- changes/bug21058 | 3 +++ doc/tor.1.txt | 33 +++++++++++++++++---------------- 2 files changed, 20 insertions(+), 16 deletions(-) diff --git a/changes/bug21058 b/changes/bug21058 new file mode 100644 index 0000000..194b529 --- /dev/null +++ b/changes/bug21058 @@ -0,0 +1,3 @@ + o Documentation (man page): + - Clarify a number of options in tor.1 and add some min/max values for + HiddenService options. Closes #21058. diff --git a/doc/tor.1.txt b/doc/tor.1.txt index 32f8908..46b1077 100644 --- a/doc/tor.1.txt +++ b/doc/tor.1.txt @@ -846,7 +846,7 @@ The following options are useful only for clients (that is, if [[ExcludeExitNodes]] **ExcludeExitNodes** __node__,__node__,__...__:: A list of identity fingerprints, country codes, and address patterns of nodes to never use when picking an exit node---that is, a - node that delivers traffic for you outside the Tor network. Note that any + node that delivers traffic for you *outside* the Tor network. Note that any node listed in ExcludeNodes is automatically considered to be part of this list too. See the **ExcludeNodes** option for more information on how to specify @@ -863,7 +863,7 @@ The following options are useful only for clients (that is, if [[ExitNodes]] **ExitNodes** __node__,__node__,__...__:: A list of identity fingerprints, country codes, and address patterns of nodes to use as exit node---that is, a - node that delivers traffic for you outside the Tor network. See + node that delivers traffic for you *outside* the Tor network. See the **ExcludeNodes** option for more information on how to specify nodes. + + Note that if you list too few nodes here, or if you exclude too many exit @@ -871,7 +871,7 @@ The following options are useful only for clients (that is, if if none of the exits you list allows traffic on port 80 or 443, you won't be able to browse the web. + + - Note also that not every circuit is used to deliver traffic outside of + Note also that not every circuit is used to deliver traffic *outside* of the Tor network. It is normal to see non-exit circuits (such as those used to connect to hidden services, those that do directory fetches, those used for relay reachability self-tests, and so on) that end @@ -897,16 +897,16 @@ The following options are useful only for clients (that is, if the **ExcludeNodes** option for more information on how to specify nodes. [[StrictNodes]] **StrictNodes** **0**|**1**:: - If StrictNodes is set to 1, Tor will treat the ExcludeNodes option as a - requirement to follow for all the circuits you generate, even if doing so - will break functionality for you. If StrictNodes is set to 0, Tor will + If StrictNodes is set to 1, Tor will treat solely the ExcludeNodes option + as a requirement to follow for all the circuits you generate, even if + doing so will break functionality for you (StrictNodes applies to neither + ExcludeExitNodes nor to ExitNodes). If StrictNodes is set to 0, Tor will still try to avoid nodes in the ExcludeNodes list, but it will err on the - side of avoiding unexpected errors. Specifically, StrictNodes 0 tells - Tor that it is okay to use an excluded node when it is *necessary* to - perform relay reachability self-tests, connect to - a hidden service, provide a hidden service to a client, fulfill a .exit - request, upload directory information, or download directory information. - (Default: 0) + side of avoiding unexpected errors. Specifically, StrictNodes 0 tells Tor + that it is okay to use an excluded node when it is *necessary* to perform + relay reachability self-tests, connect to a hidden service, provide a + hidden service to a client, fulfill a .exit request, upload directory + information, or download directory information. (Default: 0) [[FascistFirewall]] **FascistFirewall** **0**|**1**:: If 1, Tor will only create outgoing connections to ORs running on ports @@ -2412,8 +2412,8 @@ The following options are used to configure a hidden service. [[HiddenServiceMaxStreams]] **HiddenServiceMaxStreams** __N__:: The maximum number of simultaneous streams (connections) per rendezvous - circuit. (Setting this to 0 will allow an unlimited number of simultanous - streams.) (Default: 0) + circuit. The maximum value allowed is 65535. (Setting this to 0 will allow + an unlimited number of simultanous streams.) (Default: 0) [[HiddenServiceMaxStreamsCloseCircuit]] **HiddenServiceMaxStreamsCloseCircuit** **0**|**1**:: If set to 1, then exceeding **HiddenServiceMaxStreams** will cause the @@ -2422,8 +2422,9 @@ The following options are used to configure a hidden service. [[RendPostPeriod]] **RendPostPeriod** __N__ **seconds**|**minutes**|**hours**|**days**|**weeks**:: Every time the specified period elapses, Tor uploads any rendezvous - service descriptors to the directory servers. This information is also - uploaded whenever it changes. (Default: 1 hour) + service descriptors to the directory servers. This information is also + uploaded whenever it changes. Minimum value allowed is 10 minutes and + maximum is 3.5 days. (Default: 1 hour) [[HiddenServiceDirGroupReadable]] **HiddenServiceDirGroupReadable** **0**|**1**:: If this option is set to 1, allow the filesystem group to read the

1 0

[tor/master] relay: Honor DataDirectoryGroupReadable at key init
by nickm＠torproject.org 18 Jan '17

18 Jan '17

commit e16148a58218177411939e373d96aa4f152cadc8 Author: David Goulet <dgoulet(a)torproject.org> Date: Tue Jan 17 14:40:01 2017 -0500 relay: Honor DataDirectoryGroupReadable at key init Our config code is checking correctly at DataDirectoryGroupReadable but then when we initialize the keys, we ignored that option ending up at setting back the DataDirectory to 0700 instead of 0750. Patch by "redfish". Fixes #19953 Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- changes/bug19953 | 6 ++++++ src/or/router.c | 7 ++++++- src/or/routerkeys.c | 7 +++++-- 3 files changed, 17 insertions(+), 3 deletions(-) diff --git a/changes/bug19953 b/changes/bug19953 new file mode 100644 index 0000000..919018d --- /dev/null +++ b/changes/bug19953 @@ -0,0 +1,6 @@ + o Minor bugfixes (relay) + - Honor DataDirectoryGroupReadable when tor is a relay. Previously, the + initialization of the keys would reset the DataDirectory to 0700 instead + of 0750 if DataDirectoryGroupReadable was set to 1. Fixes #19953. Patch + by "redfish".; bugfix on tor-0.0.2pre16. + diff --git a/src/or/router.c b/src/or/router.c index 2d8208a..e4fa72a 100644 --- a/src/or/router.c +++ b/src/or/router.c @@ -849,7 +849,12 @@ init_keys(void) if (init_keys_common() < 0) return -1; /* Make sure DataDirectory exists, and is private. */ - if (check_private_dir(options->DataDirectory, CPD_CREATE, options->User)) { + cpd_check_t cpd_opts = CPD_CREATE; + if (options->DataDirectoryGroupReadable) + cpd_opts |= CPD_GROUP_READ; + if (check_private_dir(options->DataDirectory, cpd_opts, options->User)) { + log_err(LD_OR, "Can't create/check datadirectory %s", + options->DataDirectory); return -1; } /* Check the key directory. */ diff --git a/src/or/routerkeys.c b/src/or/routerkeys.c index 51802b1..e207871 100644 --- a/src/or/routerkeys.c +++ b/src/or/routerkeys.c @@ -785,8 +785,11 @@ load_ed_keys(const or_options_t *options, time_t now) if (options->command == CMD_KEYGEN) flags |= INIT_ED_KEY_TRY_ENCRYPTED; - /* Check the key directory */ - if (check_private_dir(options->DataDirectory, CPD_CREATE, options->User)) { + /* Check/Create the key directory */ + cpd_check_t cpd_opts = CPD_CREATE; + if (options->DataDirectoryGroupReadable) + cpd_opts |= CPD_GROUP_READ; + if (check_private_dir(options->DataDirectory, cpd_opts, options->User)) { log_err(LD_OR, "Can't create/check datadirectory %s", options->DataDirectory); goto err;

1 0