April 2018 - tor-commits - lists.torproject.org

[tor/maint-0.3.3] doc: Improve DoS section of the man page tor.1
by nickm＠torproject.org 13 Apr '18

13 Apr '18

commit 119b053a8ad9cf8139a159cda30e04d2a3887914 Author: David Goulet <dgoulet(a)torproject.org> Date: Wed Apr 4 10:22:13 2018 -0400 doc: Improve DoS section of the man page tor.1 Add to the Denial of Service section of the man page an explanation about the three different mitigation Tor has. Fixes #25248. Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- changes/ticket25248 | 4 ++++ doc/tor.1.txt | 57 ++++++++++++++++++++++++++++++++++++++++++----------- 2 files changed, 49 insertions(+), 12 deletions(-) diff --git a/changes/ticket25248 b/changes/ticket25248 new file mode 100644 index 000000000..67ccdb631 --- /dev/null +++ b/changes/ticket25248 @@ -0,0 +1,4 @@ + o Documentation (manpage, denial of service): + - Better detail the denial of service options by listing the different + mitigation in place. Closes ticket 25248. + diff --git a/doc/tor.1.txt b/doc/tor.1.txt index 9aad3af98..8bb27fa5a 100644 --- a/doc/tor.1.txt +++ b/doc/tor.1.txt @@ -2755,17 +2755,49 @@ The following options are used to configure a hidden service. DENIAL OF SERVICE MITIGATION OPTIONS ------------------------------------ +Tor has three built-in mitigation options that can be individually +enabled/disabled and fine-tuned, but by default Tor directory authorities will +define reasonable values for relays and no explicit configuration is required +to make use of these protections. The mitigations are: + + 1. If a single client address makes too many concurrent connections (this + is configurable via DoSConnectionMaxConcurrentCount), hang up on + further connections. + + + 2. If a single client IP address (v4 or v6) makes circuits too quickly + (default values are more than 3 per second, with an allowed burst of 90, + see DoSCircuitCreationRate and DoSCircuitCreationBurst) while also having + too many connections open (default is 3, see + DoSCircuitCreationMinConnections), tor will refuse any new circuit + (CREATE cells) for the next while (random value between 1 and 2 hours). + + + 3. If a client asks to establish a rendezvous point to you directly (ex: + Tor2Web client), ignore the request. + +These defenses can be manually controlled by torrc options, but relays will +also take guidance from consensus parameters, so there's no need to configure +anything manually. In doubt, do not change those values. + +The values set by the consensus, if any, can be found here: +https://consensus-health.torproject.org/#consensusparams + +If any of the DoS mitigations are enabled, an heartbeat message will appear in +your log at NOTICE level which looks like: + + DoS mitigation since startup: 429042 circuits rejected, 17 marked addresses. + 2238 connections closed. 8052 single hop clients refused. + The following options are useful only for a public relay. They control the -Denial of Service mitigation subsystem. +Denial of Service mitigation subsystem described above. [[DoSCircuitCreationEnabled]] **DoSCircuitCreationEnabled** **0**|**1**|**auto**:: - Enable circuit creation DoS mitigation. If enabled, tor will cache client - IPs along with statistics in order to detect circuit DoS attacks. If an - address is positively identified, tor will activate defenses against the - address. See the DoSCircuitCreationDefenseType option for more details. - This is a client to relay detection only. "auto" means use the consensus - parameter. If not defined in the consensus, the value is 0. + Enable circuit creation DoS mitigation. If set to 1 (enabled), tor will + cache client IPs along with statistics in order to detect circuit DoS + attacks. If an address is positively identified, tor will activate + defenses against the address. See the DoSCircuitCreationDefenseType option + for more details. This is a client to relay detection only. "auto" means + use the consensus parameter. If not defined in the consensus, the value is 0. (Default: auto) [[DoSCircuitCreationMinConnections]] **DoSCircuitCreationMinConnections** __NUM__:: @@ -2809,14 +2841,15 @@ Denial of Service mitigation subsystem. The base time period in seconds that the DoS defense is activated for. The actual value is selected randomly for each activation from N+1 to 3/2 * N. "0" means use the consensus parameter. If not defined in the consensus, - the value is 3600 seconds (1 hour). (Default: 0) + the value is 3600 seconds (1 hour). + (Default: 0) [[DoSConnectionEnabled]] **DoSConnectionEnabled** **0**|**1**|**auto**:: - Enable the connection DoS mitigation. For client address only, this allows - tor to mitigate against large number of concurrent connections made by a - single IP address. "auto" means use the consensus parameter. If not - defined in the consensus, the value is 0. + Enable the connection DoS mitigation. If set to 1 (enabled), for client + address only, this allows tor to mitigate against large number of + concurrent connections made by a single IP address. "auto" means use the + consensus parameter. If not defined in the consensus, the value is 0. (Default: auto) [[DoSConnectionMaxConcurrentCount]] **DoSConnectionMaxConcurrentCount** __NUM__::

1 0

[tor/release-0.3.3] Merge branch 'maint-0.3.3' into release-0.3.3
by nickm＠torproject.org 13 Apr '18

13 Apr '18

commit 50406c272024be63047576a19a8159bd25239164 Merge: 6963aca6a 2d6914e39 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Apr 13 13:05:53 2018 -0400 Merge branch 'maint-0.3.3' into release-0.3.3 changes/bug25691 | 6 ++++++ src/or/circuitbuild.c | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-)

1 0

[tor/master] Merge branch 'maint-0.3.3'
by nickm＠torproject.org 13 Apr '18

13 Apr '18

commit c9de30c590b7e47a6263b0e4d6b324c237b99330 Merge: 61d87dfa1 2d6914e39 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Apr 13 13:05:53 2018 -0400 Merge branch 'maint-0.3.3' changes/bug25691 | 6 ++++++ src/or/circuitbuild.c | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-)

1 0

[tor/master] Refine extend_info_for_node's "enough info" check once again.
by nickm＠torproject.org 13 Apr '18

13 Apr '18

commit 2d6914e3918230b259af3a0535ccb37eb5a77c8e Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Apr 12 16:53:53 2018 -0400 Refine extend_info_for_node's "enough info" check once again. In d1874b433953f64, we adjusted this check so that we insist on using routerinfos for bridges. That's almost correct... but if we have a bridge that is also a regular relay, then we should use insist on its routerinfo when connecting to it as a bridge (directly), and be willing to use its microdescriptor when connecting to it elsewhere in our circuits. This bug is a likely cause of some (all?) of the (exit_ei == NULL) failures we've been seeing. Fixes bug 25691; bugfix on 0.3.3.4-alpha --- changes/bug25691 | 6 ++++++ src/or/circuitbuild.c | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/changes/bug25691 b/changes/bug25691 new file mode 100644 index 000000000..5f630d503 --- /dev/null +++ b/changes/bug25691 @@ -0,0 +1,6 @@ + o Minor bugfixes (client): + - When using a listed relay as a bridge, and also using + microdescriptors, and considering that relay as a non-bridge in + a circuit, consider its microdescriptor as a valid source of information + about that relay. Fixes bug 25691; bugfix on 0.3.3.4-alpha. + diff --git a/src/or/circuitbuild.c b/src/or/circuitbuild.c index 01921bac1..5f1f8122f 100644 --- a/src/or/circuitbuild.c +++ b/src/or/circuitbuild.c @@ -2860,7 +2860,7 @@ extend_info_from_node(const node_t *node, int for_direct_connect) const int is_bridge = node_is_a_configured_bridge(node); const int we_use_mds = we_use_microdescriptors_for_circuits(get_options()); - if (is_bridge || !we_use_mds) { + if ((is_bridge && for_direct_connect) || !we_use_mds) { /* We need an ri in this case. */ if (!node->ri) return NULL;

1 0

[tor/release-0.3.3] Refine extend_info_for_node's "enough info" check once again.
by nickm＠torproject.org 13 Apr '18

13 Apr '18

commit 2d6914e3918230b259af3a0535ccb37eb5a77c8e Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Apr 12 16:53:53 2018 -0400 Refine extend_info_for_node's "enough info" check once again. In d1874b433953f64, we adjusted this check so that we insist on using routerinfos for bridges. That's almost correct... but if we have a bridge that is also a regular relay, then we should use insist on its routerinfo when connecting to it as a bridge (directly), and be willing to use its microdescriptor when connecting to it elsewhere in our circuits. This bug is a likely cause of some (all?) of the (exit_ei == NULL) failures we've been seeing. Fixes bug 25691; bugfix on 0.3.3.4-alpha --- changes/bug25691 | 6 ++++++ src/or/circuitbuild.c | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/changes/bug25691 b/changes/bug25691 new file mode 100644 index 000000000..5f630d503 --- /dev/null +++ b/changes/bug25691 @@ -0,0 +1,6 @@ + o Minor bugfixes (client): + - When using a listed relay as a bridge, and also using + microdescriptors, and considering that relay as a non-bridge in + a circuit, consider its microdescriptor as a valid source of information + about that relay. Fixes bug 25691; bugfix on 0.3.3.4-alpha. + diff --git a/src/or/circuitbuild.c b/src/or/circuitbuild.c index 01921bac1..5f1f8122f 100644 --- a/src/or/circuitbuild.c +++ b/src/or/circuitbuild.c @@ -2860,7 +2860,7 @@ extend_info_from_node(const node_t *node, int for_direct_connect) const int is_bridge = node_is_a_configured_bridge(node); const int we_use_mds = we_use_microdescriptors_for_circuits(get_options()); - if (is_bridge || !we_use_mds) { + if ((is_bridge && for_direct_connect) || !we_use_mds) { /* We need an ri in this case. */ if (!node->ri) return NULL;

1 0

[tor/maint-0.3.3] Refine extend_info_for_node's "enough info" check once again.
by nickm＠torproject.org 13 Apr '18

13 Apr '18

commit 2d6914e3918230b259af3a0535ccb37eb5a77c8e Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Apr 12 16:53:53 2018 -0400 Refine extend_info_for_node's "enough info" check once again. In d1874b433953f64, we adjusted this check so that we insist on using routerinfos for bridges. That's almost correct... but if we have a bridge that is also a regular relay, then we should use insist on its routerinfo when connecting to it as a bridge (directly), and be willing to use its microdescriptor when connecting to it elsewhere in our circuits. This bug is a likely cause of some (all?) of the (exit_ei == NULL) failures we've been seeing. Fixes bug 25691; bugfix on 0.3.3.4-alpha --- changes/bug25691 | 6 ++++++ src/or/circuitbuild.c | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/changes/bug25691 b/changes/bug25691 new file mode 100644 index 000000000..5f630d503 --- /dev/null +++ b/changes/bug25691 @@ -0,0 +1,6 @@ + o Minor bugfixes (client): + - When using a listed relay as a bridge, and also using + microdescriptors, and considering that relay as a non-bridge in + a circuit, consider its microdescriptor as a valid source of information + about that relay. Fixes bug 25691; bugfix on 0.3.3.4-alpha. + diff --git a/src/or/circuitbuild.c b/src/or/circuitbuild.c index 01921bac1..5f1f8122f 100644 --- a/src/or/circuitbuild.c +++ b/src/or/circuitbuild.c @@ -2860,7 +2860,7 @@ extend_info_from_node(const node_t *node, int for_direct_connect) const int is_bridge = node_is_a_configured_bridge(node); const int we_use_mds = we_use_microdescriptors_for_circuits(get_options()); - if (is_bridge || !we_use_mds) { + if ((is_bridge && for_direct_connect) || !we_use_mds) { /* We need an ri in this case. */ if (!node->ri) return NULL;

1 0

[stem/master] Fix recent regression in unit tests
by atagar＠torproject.org 13 Apr '18

13 Apr '18

commit a2300bebe0e59c3466ecdbb5e72d37d9faca744a Author: Damian Johnson <atagar(a)torproject.org> Date: Thu Apr 12 18:01:50 2018 -0700 Fix recent regression in unit tests Oops, change earlier today broke our mock... ====================================================================== FAIL: test_compression_gzip ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/mock/mock.py", line 1305, in patched return func(*args, **keywargs) File "/home/atagar/Desktop/stem/test/unit/descriptor/remote.py", line 181, in test_compression_gzip self.assertEqual(1, len(descriptors)) AssertionError: 1 != 0 --- test/unit/descriptor/remote.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/unit/descriptor/remote.py b/test/unit/descriptor/remote.py index cc4c3997..1dfccc09 100644 --- a/test/unit/descriptor/remote.py +++ b/test/unit/descriptor/remote.py @@ -115,7 +115,7 @@ FALLBACK_ENTRY = b"""\ def _urlopen_mock(data, encoding = 'identity'): urlopen_mock = Mock() urlopen_mock().read.return_value = data - urlopen_mock().info().getheader.return_value = encoding + urlopen_mock().info().get.return_value = encoding return urlopen_mock

1 0

[torspec/master] Fix inconsistencies on HS v3 spec and cert-spec.txt.
by nickm＠torproject.org 13 Apr '18

13 Apr '18

commit 7ad2fff7ef43678411b8e8ba6c40a1aaed27ee28 Author: George Kadianakis <desnacked(a)riseup.net> Date: Fri Apr 13 15:11:32 2018 +0300 Fix inconsistencies on HS v3 spec and cert-spec.txt. Pointed out by inkylatenoth in: https://lists.torproject.org/pipermail/tor-dev/2017-October/012527.html Fixes ticket #24544. --- cert-spec.txt | 9 ++++++--- rend-spec-v3.txt | 5 +++-- 2 files changed, 9 insertions(+), 5 deletions(-) diff --git a/cert-spec.txt b/cert-spec.txt index 05f17f4..95c303f 100644 --- a/cert-spec.txt +++ b/cert-spec.txt @@ -72,8 +72,7 @@ Before processing any certificate, parties SHOULD know which identity key it is supposed to be signed by, and then check the signature. The signature is formed by signing the first N-64 - bytes of the certificate prefixed with the string "Tor node - signing key certificate v1". + bytes of the certificate. 2.2. Basic extensions @@ -159,7 +158,6 @@ A.3. List of signature prefixes We describe various documents as being signed with a prefix. Here are those prefixes: - "Tor node signing key certificate v1" (section 2.1) "Tor router descriptor signature v1" (see dir-spec.txt) A.4. List of certified key types @@ -167,4 +165,9 @@ A.4. List of certified key types [01] ed25519 key [02] SHA256 hash of an RSA key [03] SHA256 hash of an X.509 certificate + [08] short-term HS descriptor signing key, signed with blinded public key (rend-spec-v3.txt) + [09] intro point authentication key, cross-certifying the HS descriptor + signing key (rend-spec-v3.txt) + [0B] ed25519 key derived from the curve25519 intro point encryption key, + cross-certifying the HS descriptor signing key (rend-spec-v3.txt) diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index 019b61e..fd51cb2 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -1094,7 +1094,8 @@ Table of contents: An encrypted blob, whose format is discussed in [HS-DESC-ENC] below. The blob is base64 encoded and enclosed in -----BEGIN MESSAGE---- and - ----END MESSAGE---- wrappers. + ----END MESSAGE---- wrappers. (The resulting document does not end with + a newline character.) "signature" SP signature NL @@ -2168,7 +2169,7 @@ A.2. Tor's key derivation scheme then clamp the blinding factor 'h' according to the ed25519 spec: h[0] &= 248; - h[31] &= 127; + h[31] &= 63; h[31] |= 64; and do the key derivation as follows:

1 0

[tor/master] Merge branch 'postloop_callbacks_2'
by nickm＠torproject.org 13 Apr '18

13 Apr '18

commit 61d87dfa1509aaf209ff72d7c5e091d06b191040 Merge: b152d62ce 4c03af488 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Apr 13 12:12:46 2018 -0400 Merge branch 'postloop_callbacks_2' changes/ticket25374 | 6 +++ src/common/compat_libevent.c | 115 +++++++++++++++++++++++++++++++++++++--- src/common/compat_libevent.h | 3 ++ src/or/connection_edge.c | 32 +++++++---- src/or/main.c | 66 ++++++++++------------- src/or/main.h | 1 - src/test/test_compat_libevent.c | 60 +++++++++++++++++++++ 7 files changed, 227 insertions(+), 56 deletions(-)

1 0

[tor/master] Remove tell_event_loop_to_run_external_code() per review
by nickm＠torproject.org 13 Apr '18

13 Apr '18

commit 4c03af48806ac03e5754a7531ee9e915fc2f6c8c Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Apr 13 12:11:22 2018 -0400 Remove tell_event_loop_to_run_external_code() per review (This function is no longer used.) --- src/or/main.c | 14 -------------- src/or/main.h | 1 - 2 files changed, 15 deletions(-) diff --git a/src/or/main.c b/src/or/main.c index 257af8b18..074746108 100644 --- a/src/or/main.c +++ b/src/or/main.c @@ -731,20 +731,6 @@ connection_should_read_from_linked_conn(connection_t *conn) return 0; } -/** If we called event_base_loop() and told it to never stop until it - * runs out of events, now we've changed our mind: tell it we want it to - * exit once the current round of callbacks is done, so that we can - * run external code, and then return to the main loop. */ -void -tell_event_loop_to_run_external_code(void) -{ - if (!called_loop_once) { - struct timeval tv = { 0, 0 }; - tor_libevent_exit_loop_after_delay(tor_libevent_get_base(), &tv); - called_loop_once = 1; /* hack to avoid adding more exit events */ - } -} - /** Event to run 'shutdown did not work callback'. */ static struct event *shutdown_did_not_work_event = NULL; diff --git a/src/or/main.h b/src/or/main.h index f01506fce..5ca435064 100644 --- a/src/or/main.h +++ b/src/or/main.h @@ -45,7 +45,6 @@ int connection_is_writing(connection_t *conn); MOCK_DECL(void,connection_stop_writing,(connection_t *conn)); MOCK_DECL(void,connection_start_writing,(connection_t *conn)); -void tell_event_loop_to_run_external_code(void); void tor_shutdown_event_loop_and_exit(int exitcode); int tor_event_loop_shutdown_is_pending(void);

1 0