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

[torspec/master] Add proposal 287, for real this time
by nickm＠torproject.org 30 Nov '17

30 Nov '17

commit 475662feb63a90151768fceea5926915432524b7 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 30 16:53:51 2017 -0500 Add proposal 287, for real this time --- proposals/287-reduce-lifetime.txt | 105 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 105 insertions(+) diff --git a/proposals/287-reduce-lifetime.txt b/proposals/287-reduce-lifetime.txt new file mode 100644 index 0000000..06e87d0 --- /dev/null +++ b/proposals/287-reduce-lifetime.txt @@ -0,0 +1,105 @@ +Filename: 287-reduce-lifetime.txt +Title: Reduce circuit lifetime without overloading the network +Author: Fernando Fernandez Mancera +Created: 30-Nov-2017 +Status: Open + +Motivation: + +Currently Tor users are reusing a given circuit for ten minutes (by default) +after it's first used. This time is too long because a malicious Exit relay can +trace a user's pseudonymous profile, especially if connections from multiple +protocols are put on the same circuit. + +This time it is established on MaxCircuitDirtiness parameter and by default its +value is ten minutes. + +I have been thinking in a way to fix this. The first idea that came to my mind +was to use StreamIsolationByHost and StreamIsolationByPort on it, but I wasn't +able to sort it out. + +One day, I thought "Why is time so important?" and later on I realized that +maybe focusing on the amount of bytes running through the circuit could end up +being a better approach on this problem. + +Design: + +I propose two options to reduce this problem, both based on taking into account +the amount of bytes running through a circuit. + +MaxCircuitSizeDirtiness (temporal parameter name) will take an integer field +that is contained on an interval and represents the maximum amount of bytes +that can be written/read (we need to discuss about the use of one for both) by +the circuit. If the circuit exceeds that amount, new streams won't use this +circuit anymore. + +MaxCircuitSizeDirtinessByPort (temporal parameter name) will take an array of +integers that are contained on an interval and represents the maximum amount of +bytes that can be written/read (we need to discuss about the use of one for +both) by the circuit per port (StreamIsolationByPort). This array is parallel +to the array of ports from StreamIsolationByPort. If the circuit exceeds that +amount, new streams won't use this circuit anymore. + +Regarding default values it would be useful to set up one a bit lower than the +average amount of bytes per circuit. On MaxCircuitSizeDirtinessByPort after +discuss it we shouldn't set up a default value because someone can identify the +port used. About MaxCircuitDirtiness, if the others are set up by default it +could be bigger, like thirty minutes, so if the user doesn't send/receive a +significant amount of data the circuit will be changed anyway. + +Security Implications: + +It is believed that the proposed changes will improve the anonymity for end +users. The end user won't reuse a given circuit if they have sent a +considerable amount of bytes, thus making more difficult for malicious Exit +relays to be able to trace a user's pseudonymous profile. + +Obviously this is a probability, of course it's possible that sensitive data +will leak in a little amount of data but it's more even possible that sensitive +data will leak in a large amount. + +Specification: + +In order to implement this feature we will need to add some new +functionalities. We need to parse MaxCircuitSizeDirtiness and +MaxCircuitSizeDirtinessByPort from the torrc config file. We need to create a +function or improve one to check the amount of bytes that are running through +the circuit and if this amount is higher than the established value, consider +the circuit dirty. + +Compatibility: + +The proposed changes should not create any compatibility issues. New Tor +clients will be able to take advantage of this without any modification to the +network. + +Implementation: + +It is proposed that MaxCircuitSizeDirtiness will be enabled by default and also +increase MaxCircuitDirtiness to thirty minutes. + +It is proposed that MaxCircuitSizeDirtinessByPort won't be enabled by default +for port 22, 53, and port 80 as StreamIsolationByPort. + +About TorBrowser or any other Tor application that is able to manage circuits +by its own because of KeepAliveIsolateSOCKSAuth option being active by default +shouldn't be affected by this new feature. As the same form that it currently +ignores MaxCircuitDirtiness parameter. + +Performance and scalability notes: + +The proposed changes will reduce Tor network stress as users who do not exceed +the set amount will reduce circuit generation by three (if default +MaxCircuitDirtinesss value is thirty minutes). + +I want to work on demonstrating that by a research but first it's nice to get the +idea accepted. + +References: + +Tor project research ideas [https://research.torproject.org/ideas.html] + +Enhancing Tor's Performance using Real-time Traffic Classification +[https://www.cypherpunks.ca/~iang/pubs/difftor-ccs.pdf] (It's not exactly about +that, but they talk about circuit lifetime and the ten minutes problem a few +times. Also it's an interesting paper.)

1 0

[torspec/master] Add proposal 287
by nickm＠torproject.org 30 Nov '17

30 Nov '17

commit bca928a5acb72971c67ba4cc619977d9cbd3adef Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 30 16:53:35 2017 -0500 Add proposal 287 --- proposals/000-index.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 2bb7363..dd9abdc 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -207,6 +207,7 @@ Proposals by number: 284 Hidden Service v3 Control Port [OPEN] 285 Directory documents should be standardized as UTF-8 [OPEN] 286 Controller APIs for hibernation access on mobile [OPEN] +287 Reduce circuit lifetime without overloading the network [OPEN] Proposals by status: @@ -267,6 +268,7 @@ Proposals by status: 284 Hidden Service v3 Control Port 285 Directory documents should be standardized as UTF-8 286 Controller APIs for hibernation access on mobile + 287 Reduce circuit lifetime without overloading the network ACCEPTED: 172 GETINFO controller option for circuit information 173 GETINFO Option Expansion

1 0

[tor/release-0.3.2] Merge branch 'maint-0.3.1' into maint-0.3.2
by nickm＠torproject.org 30 Nov '17

30 Nov '17

commit 25d50decb275854c312c8ee4ce5fd7e3f2945e5c Merge: f0007f2b8 500f04a74 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 30 11:48:12 2017 -0500 Merge branch 'maint-0.3.1' into maint-0.3.2

1 0

[tor/release-0.3.2] Merge branch 'bug21394_029' into maint-0.2.9
by nickm＠torproject.org 30 Nov '17

30 Nov '17

commit 072e194a15e9aa0e75c6723763a69476f4f31b93 Merge: 30b322925 982757430 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 30 11:48:06 2017 -0500 Merge branch 'bug21394_029' into maint-0.2.9 changes/bug21394 | 9 +++++++++ src/or/dns.c | 23 ++++++++++++++++++++--- 2 files changed, 29 insertions(+), 3 deletions(-)

1 0

[tor/release-0.3.2] Merge branch 'maint-0.3.2' into release-0.3.2
by nickm＠torproject.org 30 Nov '17

30 Nov '17

commit 500975da96f27037c9339ef18d474106af892478 Merge: 1e715efb7 25d50decb Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 30 11:48:12 2017 -0500 Merge branch 'maint-0.3.2' into release-0.3.2

1 0

[tor/release-0.3.2] Merge branch 'maint-0.2.9' into maint-0.3.0
by nickm＠torproject.org 30 Nov '17

30 Nov '17

commit 766d0a2d98591ed840cce42710c5a59a2e7dc731 Merge: b1c4ab0be 072e194a1 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 30 11:48:12 2017 -0500 Merge branch 'maint-0.2.9' into maint-0.3.0 changes/bug21394 | 9 +++++++++ src/or/dns.c | 23 ++++++++++++++++++++--- 2 files changed, 29 insertions(+), 3 deletions(-)

1 0

[tor/release-0.3.2] Merge branch 'maint-0.3.0' into maint-0.3.1
by nickm＠torproject.org 30 Nov '17

30 Nov '17

commit 500f04a74e22686f7659adecea02569b3459c71b Merge: 703ab95e9 766d0a2d9 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 30 11:48:12 2017 -0500 Merge branch 'maint-0.3.0' into maint-0.3.1 changes/bug21394 | 9 +++++++++ src/or/dns.c | 23 ++++++++++++++++++++--- 2 files changed, 29 insertions(+), 3 deletions(-)

1 0

[tor/maint-0.2.9] Fix DNS resolution on busy exit relays
by nickm＠torproject.org 30 Nov '17

30 Nov '17

commit 98275743081728b1538f70111c891ea573127e85 Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Fri Nov 3 03:06:12 2017 +0100 Fix DNS resolution on busy exit relays Thanks to Dhalgren who analyzed this issue two years ago and found a solution! --- changes/bug21394 | 9 +++++++++ src/or/dns.c | 23 ++++++++++++++++++++--- 2 files changed, 29 insertions(+), 3 deletions(-) diff --git a/changes/bug21394 b/changes/bug21394 new file mode 100644 index 000000000..e5452e20b --- /dev/null +++ b/changes/bug21394 @@ -0,0 +1,9 @@ + o Major bugfixes (Exit nodes): + - Fix an issue causing high-bandwidth exit nodes to fail a majority + or all of their DNS requests, making them basically unsuitable for + regular usage in Tor circuits. The problem is related to + libevent's DNS handling, but we can work around it in Tor. Fixes + bugs 21394 and 18580; bugfix on 0.1.2.2-alpha which introduced + eventdns. Credit goes to Dhalgren for identifying and finding a + workaround to this bug and to gamambel, arthuredelstein and + arma in helping to track it down and analyze it. diff --git a/src/or/dns.c b/src/or/dns.c index 0ad4c0f50..c1e3c3256 100644 --- a/src/or/dns.c +++ b/src/or/dns.c @@ -1425,14 +1425,31 @@ configure_nameservers(int force) #define SET(k,v) evdns_base_set_option(the_evdns_base, (k), (v)) + // If we only have one nameserver, it does not make sense to back off + // from it for a timeout. Unfortunately, the value for max-timeouts is + // currently clamped by libevent to 255, but it does not hurt to set + // it higher in case libevent gets a patch for this. + // Reducing attempts in the case of just one name server too, because + // it is very likely to be a local one where a network connectivity + // issue should not cause an attempt to fail. if (evdns_base_count_nameservers(the_evdns_base) == 1) { - SET("max-timeouts:", "16"); - SET("timeout:", "10"); + SET("max-timeouts:", "1000000"); + SET("attempts:", "1"); } else { SET("max-timeouts:", "3"); - SET("timeout:", "5"); } + // Elongate the queue of maximum inflight dns requests, so if a bunch + // time out at the resolver (happens commonly with unbound) we won't + // stall every other DNS request. This potentially means some wasted + // CPU as there's a walk over a linear queue involved, but this is a + // much better tradeoff compared to just failing DNS requests because + // of a full queue. + SET("max-inflight:", "8192"); + + // Time out after 5 seconds if no reply. + SET("timeout:", "5"); + if (options->ServerDNSRandomizeCase) SET("randomize-case:", "1"); else

1 0

[tor/maint-0.3.1] Fix DNS resolution on busy exit relays
by nickm＠torproject.org 30 Nov '17

30 Nov '17

commit 98275743081728b1538f70111c891ea573127e85 Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Fri Nov 3 03:06:12 2017 +0100 Fix DNS resolution on busy exit relays Thanks to Dhalgren who analyzed this issue two years ago and found a solution! --- changes/bug21394 | 9 +++++++++ src/or/dns.c | 23 ++++++++++++++++++++--- 2 files changed, 29 insertions(+), 3 deletions(-) diff --git a/changes/bug21394 b/changes/bug21394 new file mode 100644 index 000000000..e5452e20b --- /dev/null +++ b/changes/bug21394 @@ -0,0 +1,9 @@ + o Major bugfixes (Exit nodes): + - Fix an issue causing high-bandwidth exit nodes to fail a majority + or all of their DNS requests, making them basically unsuitable for + regular usage in Tor circuits. The problem is related to + libevent's DNS handling, but we can work around it in Tor. Fixes + bugs 21394 and 18580; bugfix on 0.1.2.2-alpha which introduced + eventdns. Credit goes to Dhalgren for identifying and finding a + workaround to this bug and to gamambel, arthuredelstein and + arma in helping to track it down and analyze it. diff --git a/src/or/dns.c b/src/or/dns.c index 0ad4c0f50..c1e3c3256 100644 --- a/src/or/dns.c +++ b/src/or/dns.c @@ -1425,14 +1425,31 @@ configure_nameservers(int force) #define SET(k,v) evdns_base_set_option(the_evdns_base, (k), (v)) + // If we only have one nameserver, it does not make sense to back off + // from it for a timeout. Unfortunately, the value for max-timeouts is + // currently clamped by libevent to 255, but it does not hurt to set + // it higher in case libevent gets a patch for this. + // Reducing attempts in the case of just one name server too, because + // it is very likely to be a local one where a network connectivity + // issue should not cause an attempt to fail. if (evdns_base_count_nameservers(the_evdns_base) == 1) { - SET("max-timeouts:", "16"); - SET("timeout:", "10"); + SET("max-timeouts:", "1000000"); + SET("attempts:", "1"); } else { SET("max-timeouts:", "3"); - SET("timeout:", "5"); } + // Elongate the queue of maximum inflight dns requests, so if a bunch + // time out at the resolver (happens commonly with unbound) we won't + // stall every other DNS request. This potentially means some wasted + // CPU as there's a walk over a linear queue involved, but this is a + // much better tradeoff compared to just failing DNS requests because + // of a full queue. + SET("max-inflight:", "8192"); + + // Time out after 5 seconds if no reply. + SET("timeout:", "5"); + if (options->ServerDNSRandomizeCase) SET("randomize-case:", "1"); else

1 0

[tor/maint-0.3.2] Merge branch 'bug21394_029' into maint-0.2.9
by nickm＠torproject.org 30 Nov '17

30 Nov '17

commit 072e194a15e9aa0e75c6723763a69476f4f31b93 Merge: 30b322925 982757430 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Nov 30 11:48:06 2017 -0500 Merge branch 'bug21394_029' into maint-0.2.9 changes/bug21394 | 9 +++++++++ src/or/dns.c | 23 ++++++++++++++++++++--- 2 files changed, 29 insertions(+), 3 deletions(-)

1 0