tor-commits April 2014

tor-commits@lists.torproject.org

22 participants
2020 discussions

[translation/https_everywhere] Update translations for https_everywhere
by translation＠torproject.org 24 Apr '14

24 Apr '14

commit 9036078a3b0f535d94909ae87394c6757224e76d Author: Translation commit bot <translation(a)torproject.org> Date: Thu Apr 24 03:45:17 2014 +0000 Update translations for https_everywhere --- id/ssl-observatory.dtd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/id/ssl-observatory.dtd b/id/ssl-observatory.dtd index 0e84d0c..6170c87 100644 --- a/id/ssl-observatory.dtd +++ b/id/ssl-observatory.dtd @@ -78,7 +78,7 @@ looked at. Mouseover the options for further details:"> <!ENTITY ssl-observatory.prefs.priv_dns_tooltip "Unless this option is checked, the Observatory will not record certificates for names that it cannot resolve through the DNS system."> -<!ENTITY ssl-observatory.prefs.show "Show advanced options"> +<!ENTITY ssl-observatory.prefs.show "Tampilkan opsi lanjutan"> <!ENTITY ssl-observatory.prefs.title "Preferensi pengamatan SSL">

1 0

[translation/whisperback] Update translations for whisperback
by translation＠torproject.org 24 Apr '14

24 Apr '14

commit e26654176a95da54109df7120ffb811fe60fa7a0 Author: Translation commit bot <translation(a)torproject.org> Date: Thu Apr 24 03:45:12 2014 +0000 Update translations for whisperback --- id/id.po | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/id/id.po b/id/id.po index 4238022..69a8398 100644 --- a/id/id.po +++ b/id/id.po @@ -4,14 +4,15 @@ # # Translators: # berespost <berespost(a)gmail.com>, 2013 +# Fate Han <night.ataraxia(a)gmail.com>, 2014 # Mohamad Hasan Al Banna, 2013 msgid "" msgstr "" "Project-Id-Version: The Tor Project\n" -"Report-Msgid-Bugs-To: https://trac.torproject.org/projects/tor\n" -"POT-Creation-Date: 2013-08-01 15:36+0200\n" -"PO-Revision-Date: 2013-08-28 19:11+0000\n" -"Last-Translator: Mohamad Hasan Al Banna\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2014-03-17 17:40+0100\n" +"PO-Revision-Date: 2014-04-24 03:37+0000\n" +"Last-Translator: Fate Han <night.ataraxia(a)gmail.com>\n" "Language-Team: Indonesian (http://www.transifex.com/projects/p/torproject/language/id/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -133,7 +134,7 @@ msgstr "" #: ../data/whisperback.ui.h:1 msgid "Copyright © 2009-2012 tails(a)boum.org" -msgstr "" +msgstr "Hak Cipta © 2009-2012 tails(a)boum.org" #: ../data/whisperback.ui.h:3 msgid "https://tails.boum.org/" @@ -170,7 +171,7 @@ msgstr "Ringkasan" #: ../data/whisperback.ui.h:23 msgid "Bug description" -msgstr "" +msgstr "Deskripsi bug" #: ../data/whisperback.ui.h:24 msgid "Optional email address to contact you" @@ -198,4 +199,4 @@ msgstr "Bantuan" #: ../data/whisperback.ui.h:30 msgid "Send" -msgstr "" +msgstr "Kirim"

1 0

[translation/torbutton-torbuttonproperties] Update translations for torbutton-torbuttonproperties
by translation＠torproject.org 24 Apr '14

24 Apr '14

commit 213b4ea3ae157bee8e4aa0c40dbd9b442895fdd6 Author: Translation commit bot <translation(a)torproject.org> Date: Thu Apr 24 02:15:45 2014 +0000 Update translations for torbutton-torbuttonproperties --- km/torbutton.properties | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/km/torbutton.properties b/km/torbutton.properties index 7fc8239..86b04b7 100644 --- a/km/torbutton.properties +++ b/km/torbutton.properties @@ -21,13 +21,13 @@ torbutton.popup.test.auto_failed = បានបរាជ័យក្នុ torbutton.prefs.recommended = (បានផ្ដល់អនុសាសន៍) torbutton.prefs.optional = (ជាជម្រើស) torbutton.prefs.crucial = (ចាំបាច់) -torbutton.popup.external.title = Download an external file type? -torbutton.popup.external.app = Tor Browser cannot display this file. You will need to open it with another application.\n\n -torbutton.popup.external.note = Some types of files can cause applications to connect to the Internet without using Tor.\n\n -torbutton.popup.external.suggest = To be safe, you should only open downloaded files while offline, or use a Tor Live CD such as Tails.\n -torbutton.popup.launch = Download file +torbutton.popup.external.title = ទាញយកប្រភេទឯកសារខាងក្រៅ? +torbutton.popup.external.app = Tor Browser មិនអាចបង្ហាញឯកសារនេះ។ អ្នកនឹងត្រូវបើកវាជាមួយកម្មវិធីផ្សេង។\n +torbutton.popup.external.note = ប្រភេទឯកសារមួយចំនួនអាចធ្វើឲ្យកម្មវិធីភ្ជាប់អ៊ីនធឺណិតដោយមិនប្រើ Tor ។\n\n +torbutton.popup.external.suggest = ដើម្បីសុវត្ថិភាព អ្នកគួរតែបើកឯកសារបានទាញយកខណៈពេលនៅក្រៅបណ្ដាញ ឬប្រើស៊ីឌីផ្ទាល់ Tor ដូចជា Tails ។\n +torbutton.popup.launch = ទាញយកឯកសារ torbutton.popup.cancel = បោះបង់ -torbutton.popup.dontask = Automatically download files from now on +torbutton.popup.dontask = ទាញយកឯកសារដោយស្វ័យប្រវត្តិពីឥឡូវ torbutton.popup.test.no_http_proxy = ការសាកល្បងប្រូកស៊ីរបស់ Tor ៖ ប្រូកស៊ីរបស់ HTTP មូលដ្ឋានមិនអាចទៅដល់។ តើ Polipo កំពុងដំណើរការត្រឹមត្រូវឬ? torbutton.popup.captcha.title = ជៀសវាង Google Captchas? torbutton.popup.captcha.ask = Torbutton បានរកឃើញ Google Captcha ។ តើអ្នកចង់ទៅម៉ាស៊ីនស្វែងរកផ្សេងៗទៀតផ្ទាល់ឡើងវិញសម្រាប់សំណួរនេះឬ?

1 0

r26728: {website} Replaced references to obfs2 with references to obfs3. (website/trunk/projects/en)
by Matt Pagan 23 Apr '14

23 Apr '14

Author: mttp Date: 2014-04-23 19:07:35 +0000 (Wed, 23 Apr 2014) New Revision: 26728 Modified: website/trunk/projects/en/obfsproxy-debian-instructions.wml website/trunk/projects/en/obfsproxy-instructions.wml Log: Replaced references to obfs2 with references to obfs3. Modified: website/trunk/projects/en/obfsproxy-debian-instructions.wml =================================================================== --- website/trunk/projects/en/obfsproxy-debian-instructions.wml 2014-04-23 19:03:44 UTC (rev 26727) +++ website/trunk/projects/en/obfsproxy-debian-instructions.wml 2014-04-23 19:07:35 UTC (rev 26728) @@ -42,7 +42,7 @@ APT repository</a> and run the specified commands to install <code>tor</code> and <code>deb.torproject.org-keyring</code>. You need Tor 0.2.4.x because it knows how to automatically report your obfsproxy address to <a - href="https://bridges.torproject.org/?transport=obfs2">BridgeDB</a>. + href="https://bridges.torproject.org/?transport=obfs3">BridgeDB</a>. <h3>Step 1: Install obfsproxy</h3> @@ -124,7 +124,6 @@ <pre style="margin: 1.5em 0 1.5em 2em"> -Oct 05 20:00:41.000 [notice] Registered server transport 'obfs2' at '0.0.0.0:26821 Oct 05 20:00:41.000 [notice] Registered server transport 'obfs3' at '0.0.0.0:42000 </pre> @@ -135,7 +134,7 @@ time Tor starts, but Tor will cache and reuse the same number in future runs.) If you want to change the number, use Tor 0.2.4.7-alpha or later, and set something similar to - "ServerTransportListenAddr obfs2 0.0.0.0:26821" in your torrc. + "ServerTransportListenAddr obfs3 0.0.0.0:26821" in your torrc. </div> Modified: website/trunk/projects/en/obfsproxy-instructions.wml =================================================================== --- website/trunk/projects/en/obfsproxy-instructions.wml 2014-04-23 19:03:44 UTC (rev 26727) +++ website/trunk/projects/en/obfsproxy-instructions.wml 2014-04-23 19:07:35 UTC (rev 26728) @@ -134,7 +134,6 @@ lines similar to these: - <tt>Oct 05 20:00:41.000 [notice] Registered server transport 'obfs2' at '0.0.0.0:26821</tt> <tt>Oct 05 20:00:42.000 [notice] Registered server transport 'obfs3' at '0.0.0.0:40172</tt> @@ -143,7 +142,7 @@ firewall. (This port is randomly chosen the first time Tor starts, but Tor will cache and reuse the same number in future runs.) If you want to change the number, use Tor 0.2.4.7-alpha or later, and set - "ServerTransportListenAddr obfs2 0.0.0.0:26821" in your torrc. + "ServerTransportListenAddr obfs3 0.0.0.0:26821" in your torrc.

1 0

r26727: {website} When running Ubuntu shell scripts, ask every time. (website/trunk/docs/en)
by Matt Pagan 23 Apr '14

23 Apr '14

Author: mttp Date: 2014-04-23 19:03:44 +0000 (Wed, 23 Apr 2014) New Revision: 26727 Modified: website/trunk/docs/en/faq.wml Log: When running Ubuntu shell scripts, ask every time. Modified: website/trunk/docs/en/faq.wml =================================================================== --- website/trunk/docs/en/faq.wml 2014-04-22 16:11:08 UTC (rev 26726) +++ website/trunk/docs/en/faq.wml 2014-04-23 19:03:44 UTC (rev 26727) @@ -1192,8 +1192,8 @@ You'll need to tell Ubuntu that you want the ability to execute shell scripts from the graphical interface. Open "Files" (Unity's explorer), open -Preferences-> Behavior Tab -> Check "Run executable text files when they are -opened" then OK. +Preferences-> Behavior Tab -> Set "Run executable text files when they are +opened" to "Ask every time", then OK. You can also start the Tor Browser from the command line by running <pre>./start-tor-browser</pre>

1 0

[tor/master] copy all the changes files into the changelog again. still unedited
by nickm＠torproject.org 23 Apr '14

23 Apr '14

commit aa1ad30fc9c629eea44d715041f29e4838ff3175 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Apr 23 14:59:38 2014 -0400 copy all the changes files into the changelog again. still unedited --- ChangeLog | 32 ++++++++++++++++++++++++++++++++ changes/11543 | 8 -------- changes/bug10268 | 6 ------ changes/bug11156 | 5 ----- changes/bug11200 | 5 ----- changes/bug9229_025 | 5 ----- changes/bug9963 | 5 ----- changes/ticket11528 | 6 ------ 8 files changed, 32 insertions(+), 40 deletions(-) diff --git a/ChangeLog b/ChangeLog index 790d1d4..aa932df 100644 --- a/ChangeLog +++ b/ChangeLog @@ -43,6 +43,11 @@ Changes in version 0.2.5.4-alpha - 2014-04-?? break ties by preferring AES256 to AES128.) This resolves bugs #11513, #11492, #11498, #11499. Bugs reported by 'cypherpunks'. Bugfix on 0.2.4.8-alpha. + - Servers now trust themselves to have a better view than clients of + which TLS ciphersuites to choose. (Thanks to #11513, the server + list is now well-considered, whereas the client list has been + chosen mainly for anti-fingerprinting purposes.) Resolves ticket + 11528. o Major bugfixes (undefined behavior): - Fix two instances of possible undefined behavior in channeltls.c @@ -70,6 +75,14 @@ Changes in version 0.2.5.4-alpha - 2014-04-?? connection. This prevents controllers from declaring that a connection has failed because of "DONE" or other junk reasons. Fixes bug 10431; bugfix on 0.2.1.1-alpha. + - Improve the warning message when trying to enable the Linux + sandbox code on a Tor built without libseccomp. Instead of + saying "Sandbox is not implemented on this platform", we now + explain that we to need be built with libseccomp. Fixes bug + 11543; bugfix on 0.2.5.1-alpha. + - Avoid generating spurious warnings and failure messages when + starting with DisableNetwork enabled. Fixes bug 11200 and bug + 10405; bugfix on 0.2.3.9-alpha. o Minor bugfixes (closing channels): - If write_to_buf() in connection_write_to_buf_impl_() ever fails, @@ -127,6 +140,20 @@ Changes in version 0.2.5.4-alpha - 2014-04-?? - Stop accepting bridge lines containing hostnames. Doing so allowed clients to perform DNS requests on the hostnames, which was not sensible behavior. Fixes bug 10801; bugfix on 0.2.0.1-alpha. + - Fix a bug where a client-side Tor with pluggable transports + would take 60 seconds to bootstrap if a config re-read was + triggered at just the right timing during bootstrap. Refixes bug + 11156; bugfix on 0.2.5.3-alpha. + - Avoid 60-second delays in the bootstrapping process when Tor + is launching for a second time while using bridges. Fixes bug 9229; + bugfix on 0.2.0.3-alpha. + + o Minor bugfixes (DNS): + - When receing a DNS query for an unsupported type, reply with + no answer rather than with a NOTIMPL error. This behavior isn't + correct either, but it will break fewer client programs, we hope. + Fixes bug 10268; bugfix on 0.2.0.1-alpha. Original patch + from "epoch". o Minor bugfixes (exit): - Stop leaking memory when we successfully resolve a PTR record. @@ -152,6 +179,11 @@ Changes in version 0.2.5.4-alpha - 2014-04-?? - Demote the message that we give when a flushing connection times out for too long from NOTICE to INFO. It was usually meaningless. Resolves ticket 5286. + - Don't log so many notice-level bootstrapping messages at startup about + downloading descriptors. Previously, we'd log a notice whenever we + learned about more routers. Now, we only log a notice at every 5% of + progress. Fixes bug 9963. + o Minor features (performance, compatibility): - Update the list of TLS cipehrsuites that a client advertises diff --git a/changes/11543 b/changes/11543 deleted file mode 100644 index ebc22f7..0000000 --- a/changes/11543 +++ /dev/null @@ -1,8 +0,0 @@ - o Minor bugfixes: - - - Improve the warning message when trying to enable the Linux - sandbox code on a Tor built without libseccomp. Instead of - saying "Sandbox is not implemented on this platform", we now - explain that we to need be built with libseccomp. Fixes bug - 11543; bugfix on 0.2.5.1-alpha. - diff --git a/changes/bug10268 b/changes/bug10268 deleted file mode 100644 index 3035e76..0000000 --- a/changes/bug10268 +++ /dev/null @@ -1,6 +0,0 @@ - o Minor bugfixes: - - When receing a DNS query for an unsupported type, reply with - no answer rather than with a NOTIMPL error. This behavior isn't - correct either, but it will break fewer client programs, we hope. - Fixes bug 10268; bugfix on 0.2.0.1-alpha. Original patch - from "epoch". diff --git a/changes/bug11156 b/changes/bug11156 deleted file mode 100644 index bb20ed1e..0000000 --- a/changes/bug11156 +++ /dev/null @@ -1,5 +0,0 @@ - o Minor bugfixes (clients): - - Fix a bug where a client-side Tor with pluggable transports - would take 60 seconds to bootstrap if a config re-read was - triggered at just the right timing during bootstrap. Refixes bug - 11156; bugfix on 0.2.5.3-alpha. \ No newline at end of file diff --git a/changes/bug11200 b/changes/bug11200 deleted file mode 100644 index b4b61c9..0000000 --- a/changes/bug11200 +++ /dev/null @@ -1,5 +0,0 @@ - - Minor bugfixes: - - - Avoid generating spurious warnings and failure messages when - starting with DisableNetwork enabled. Fixes bug 11200 and bug - 10405; bugfix on 0.2.3.9-alpha. diff --git a/changes/bug9229_025 b/changes/bug9229_025 deleted file mode 100644 index ad7fd22..0000000 --- a/changes/bug9229_025 +++ /dev/null @@ -1,5 +0,0 @@ - o Minor bugfixes: - - Avoid 60-second delays in the bootstrapping process when Tor - is launching for a second time while using bridges. Fixes bug 9229; - bugfix on 0.2.0.3-alpha. - diff --git a/changes/bug9963 b/changes/bug9963 deleted file mode 100644 index b8b95f2..0000000 --- a/changes/bug9963 +++ /dev/null @@ -1,5 +0,0 @@ - o Minor features: - - Don't log so many notice-level bootstrapping messages at startup about - downloading descriptors. Previously, we'd log a notice whenever we - learned about more routers. Now, we only log a notice at every 5% of - progress. Fixes bug 9963. diff --git a/changes/ticket11528 b/changes/ticket11528 deleted file mode 100644 index 15daad9..0000000 --- a/changes/ticket11528 +++ /dev/null @@ -1,6 +0,0 @@ - o Minor features: - - Servers now trust themselves to have a better view than clients of - which TLS ciphersuites to choose. (Thanks to #11513, the server - list is now well-considered, whereas the client list has been - chosen mainly for anti-fingerprinting purposes.) Resolves ticket - 11528.

1 0

[torspec/master] Nick Hopper changes
by nickm＠torproject.org 23 Apr '14

23 Apr '14

commit 667b1c457bf6c16029887038b035405ab0baef1f Author: George Kadianakis <desnacked(a)riseup.net> Date: Thu Apr 17 21:30:16 2014 +0300 Nick Hopper changes Acked-by: George Kadianakis <desnacked(a)riseup.net> --- proposals/xxx-single-guard-node.txt | 65 +++++++++++++++++++++-------------- 1 file changed, 39 insertions(+), 26 deletions(-) diff --git a/proposals/xxx-single-guard-node.txt b/proposals/xxx-single-guard-node.txt index 94cb736..f47735f 100644 --- a/proposals/xxx-single-guard-node.txt +++ b/proposals/xxx-single-guard-node.txt @@ -2,7 +2,7 @@ Filename: xxx-single-guard-node.txt Title: The move to a single guard node Author: George Kadianakis Created: 2014-03-22 -Status: Draft and potentially a bad idea +Status: Draft 0. Introduction @@ -37,7 +37,10 @@ Status: Draft and potentially a bad idea A Guard node is considered unusable according to section "5. Guard nodes" in path-spec.txt. The rest of the rules from that section - apply here too. XXX which rules specifically? + apply here too. XXX which rules specifically? -asn + XXX Probably the rules about how to add a new guard (only after + contact), when to re-try a guard for reachability, and when to + discard a guard? -nickhopper XXX Do we need to specify how already existing clients migrate? @@ -98,36 +101,46 @@ Status: Draft and potentially a bad idea 1.3. Age of guard as a factor on guard probabilities By increasing the guard rotation period we also increase the lack - of clients for young guards since clients will rotate guards even + of utilization for young guards since clients will rotate guards even more infrequently now (see 'Phase three' of [1]). - We can try to mitigate this phenomenon by giving higher priority to - young guards to be picked as guards: + We can mitigate this phenomenon by treating these recent guards as + "fractional" guards: To do so, everytime an authority needs to vote for a guard, it - reads a set of consensus documents spanning the past NNN months, and - calculates the age of the guard; that is, in how many consensuses - its public key has been included in the past. + reads a set of consensus documents spanning the past NNN months, + where NNN is the number of months in the guard rotation period (10 + months if this proposal is adopted in full) and calculates the + visibility of the guard; that is, in how many consensuses it has + had the guard flag. The authorities include the age of each guard by appending - '[SP "Age=" INT]' in the guard's "w" line. - - When a client picks a guard, it applies the age of each guard as a - weight on its guard probability. XXX unspecified how - - XXX How much should the age of a guard influence its probability? - Should we say that a guard that just appeared should have 10% - more chance of being selected as a guard node than the oldest - guard in town? - - XXX Should the authorities include the age itself, or just the - weight that clients should apply to the probability? - - XXX Is this risky? Maybe we shouldn't give too much priority to new - guards, otherwise an adversary can start up a few new relays - every month, enjoy maximum priority when they get the guard - flag, leave them running for a bit till the next batch gets the - guard flag and then trash them. + '[SP "GV=" INT]' in the guard's "w" line. + + A guard N that has been visible for V out of NNN*30*24 consensuses + has had the opportunity to be chosen as a guard by approximately + F = V/NNN*30*24 of the clients in the network, and the remaining + 1-F fraction of the clients have not noticed this change. So when + being chosen for middle or exit positions on a circuit, clients + should treat N as if F fraction of its bandwidth is a guard + (respectively, dual) node and (1-F) is a middle (resp, exit) node. + Let Wpf denote the weight from the 'bandwidth-weights' line a + client would apply to N for position p if it had the guard + flag, Wpn the weight if it did not have the guard flag, and B the + measured bandwidth of N in the consensus. Then instead of choosing + N for position p proportionally to Wpf*B or Wpn*B, clients should + choose N proportionally to F*Wpf*B + (1-F)*Wpn*B. + + Similarly, when calculating the bandwidth-weights line as in + section 3.8.3 of dir-spec.txt, directory authorities should treat N + as if fraction F of its bandwidth has the guard flag and (1-F) does + not. So when computing the totals G,M,E,D, each relay N with guard + visibility fraction F and bandwidth B should be added as follows: + + G' = G + F*B, if N does not have the exit flag + M' = M + (1-F)*B, if N does not have the exit flag + D' = D + F*B, if N has the exit flag + E' = E + (1-F)*B, if N has the exit flag 1.4. Raise the bandwidth threshold for being a guard

1 0

[torspec/master] Add xxx-single-guard-node.txt .
by nickm＠torproject.org 23 Apr '14

23 Apr '14

commit d88aa2b009af679172881ecc8891da32a56b9ea9 Author: George Kadianakis <desnacked(a)riseup.net> Date: Wed Apr 16 04:43:20 2014 +0300 Add xxx-single-guard-node.txt . --- proposals/xxx-single-guard-node.txt | 274 +++++++++++++++++++++++++++++++++++ 1 file changed, 274 insertions(+) diff --git a/proposals/xxx-single-guard-node.txt b/proposals/xxx-single-guard-node.txt new file mode 100644 index 0000000..94cb736 --- /dev/null +++ b/proposals/xxx-single-guard-node.txt @@ -0,0 +1,274 @@ +Filename: xxx-single-guard-node.txt +Title: The move to a single guard node +Author: George Kadianakis +Created: 2014-03-22 +Status: Draft and potentially a bad idea + +0. Introduction + + It has been suggested that reducing the number of guard nodes of + each user and increasing the guard node rotation period will make + Tor more resistant against certain attacks [0]. + + For example, an attacker who sets up guard nodes and hopes for a + client to eventually choose them as their guard will have much less + probability of succeeding in the long term. + + Currently, every client picks 3 guard nodes and keeps them for 2 to + 3 months (since 0.2.4.12-alpha) before rotating them. In this + document, we propose the move to a single guard per client and an + increase of the rotation period to 9 to 10 months. + +1. Proposed changes + +1.1. Switch to one guard per client + + When this proposal becomes effective, clients will switch to using + a single guard node. + + That is, in its first startup, Tor picks one guard and stores its + identity persistently to disk. Tor uses that guard node as the + first hop of its circuits from thereafter. + + If that Guard node ever becomes unusable, rather than replacing it, + Tor picks a new guard and adds it to the end of the list. When + choosing the first hop of a circuit, Tor tries all guard nodes from + the top of the list sequentially till it finds a usable guard node. + + A Guard node is considered unusable according to section "5. Guard + nodes" in path-spec.txt. The rest of the rules from that section + apply here too. XXX which rules specifically? + + XXX Do we need to specify how already existing clients migrate? + +1.1.1. Alternative behavior to section 1.1 + + Here is an alternative behavior than the one specified in the + previous section. It's unclear which one is better. + + Instead of picking a new guard when the old guard becomes unusable, + we pick a number of guards in the beginning but only use the top + usable guard each time. When our guard becomes unusable, we move to + the guard below it in the list. + + This behavior _might_ make some attacks harder; for example, an + attacker who shoots down your guard in the hope that you will pick + his guard next, is now forced to have evil guards in the network at + the time you first picked your guards. + + However, this behavior might also influence performance, since a + guard that was fast enough 7 months ago, might not be this fast + today. Should we reevaluate our opinion based on the last + consensus, when we have to pick a new guard? Also, a guard that was + up 7 months ago might be down today, so we might end up sampling + from the current network anyway. + +1.2. Increase guard rotation period + + When this proposal becomes effective, Tor clients will set the + lifetime of each guard to a random time between 9 to 10 months. + + If Tor tries to use a guard whose age is over its lifetime value, + the guard gets discarded (also from persistent storage) and a new + one is picked in its place. + + XXX We didn't do any analysis on extending the rotation period. + For example, we don't even know the average age of guards, and + whether all guards stay around for less than 9 months anyway. + Maybe we should do some analysis before proceeding? + + XXX The guard lifetime should be controlled using the + (undocumented?) GuardLifetime consensus option, right? + +1.2.1. Alternative behavior to section 1.2 + + Here is an alternative behavior than the one specified in the + previous section. It's unclear which one is better. + + Similar to section 1.2, but instead of rotating to completely new + guard nodes after 9 months, we pick a few extra guard nodes in the + beginning, and after 9 months we delete the already used guard + nodes and use the one after them. + + This has approximately the same tradeoffs as section 1.1.1. + + Also, should we check the age of all of our guards periodically, or + only check them when we try to use them? + +1.3. Age of guard as a factor on guard probabilities + + By increasing the guard rotation period we also increase the lack + of clients for young guards since clients will rotate guards even + more infrequently now (see 'Phase three' of [1]). + + We can try to mitigate this phenomenon by giving higher priority to + young guards to be picked as guards: + + To do so, everytime an authority needs to vote for a guard, it + reads a set of consensus documents spanning the past NNN months, and + calculates the age of the guard; that is, in how many consensuses + its public key has been included in the past. + + The authorities include the age of each guard by appending + '[SP "Age=" INT]' in the guard's "w" line. + + When a client picks a guard, it applies the age of each guard as a + weight on its guard probability. XXX unspecified how + + XXX How much should the age of a guard influence its probability? + Should we say that a guard that just appeared should have 10% + more chance of being selected as a guard node than the oldest + guard in town? + + XXX Should the authorities include the age itself, or just the + weight that clients should apply to the probability? + + XXX Is this risky? Maybe we shouldn't give too much priority to new + guards, otherwise an adversary can start up a few new relays + every month, enjoy maximum priority when they get the guard + flag, leave them running for a bit till the next batch gets the + guard flag and then trash them. + +1.4. Raise the bandwidth threshold for being a guard + + From dir-spec.txt: + "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 median or at least 250KB/s. + + When this proposal becomes effective, authorities should change the + bandwidth threshold for being a guard node to 2000KB/s instead of + 250KB/s. + + Implications of raising the bandwidth threshold are discussed in + section 2.3. + + XXX Is this insane? It's an 8-fold increase. + +2. Discussion + +2.1. Guard node set fingerprinting + + With the old behavior of three guard nodes per user, it was + extremely unlikely for two users to have the same guard node + set. Hence the set of guard nodes acted as a fingerprint to each + user. + + When this proposal becomes effective, each user will have one guard + node. We believe that this slightly reduces the effectiveness of + this fingerprint since users who pick a popular guard node will now + blend in with thousands of other users. However, clients who pick a + slow guard will still have a small anonymity set [2]. + + All in all, this proposal slightly improves the situation of guard + node fingerprinting, but does not solve it. See the next section + for a suggested scheme that would further fix the guard node set + fingerprinting problem + +2.1.1. Potential fingerprinting solution: Guard buckets + + One of the suggested alternatives that moves us closer to solving + the guard node fingerprinting problem, would be to split the list + of N guard nodes into buckets of K guards, and have each client + pick a bucket [3]. + + This reduces the fingerprint from N-choose-k to N/k guard set + choices; it also allows users to have multiple guard nodes which + provides reliability and performance. + + Unfortunately, the implementation of this idea is not as easy and + its anonymity effects are not well understood so we had to reject + this alternative for now. + +2.2. What about 'multipath' schemes like Conflux? + + By switching to one guard, we rule out the deployment of + 'multipath' systems like Conflux [4] which build multiple circuits + through the Tor network and attempt to detect and use the most + efficient circuits. + + On the other hand, the 'Guard buckets' idea outlined in section + 2.1.1 works well with Conflux-type schemes so it's still worth + considering. + +2.3. Implications of raising the bandwidth threshold for guards + + By raising the bandwidth threshold for being a guard we directly + affect the performance and anonymity of Tor clients. We performed a + brief analysis of the implications of switching to one guard and + the results imply that the changes are not tragic [2]. + + Specifically, it seems that the performance of about half of the + clients will degrade slightly, but the performance of the other + half will remain the same or even improve. + + Also, it seems that the powerful guard nodes of the Tor network + have enough total bandwidth capacity to handle client traffic even + if some slow guard nodes get discarded. + + On the anonymity side, by increasing the bandwidth threshold to + 2MB/s we half our guard nodes; we discard 1000 out of 2000 + guards. Even if this seems like a substantial diversity loss, it + seems that the 1000 discarded guard nodes had a very small chance + of being selected in the first place (7% chance of any of the being + selected). + + However, it's worth noting that the performed analysis was quite + brief and the implications of this proposal are complex, so we + should be prepared for surprises. + +2.4. Should we stop building circuits after a number of guard failures? + + Inspired by academic papers like the Sniper attack [5], a powerful + attacker can choose to shut down guard nodes till a client is + forced to pick an attacker controlled guard node. Similarly, a + local network attacker can kill all connections towards all guards + except the ones she controls. + + This is a very powerful attack that is hard to defend against. A + naive way of defending against it would be for Tor to refuse to + build any more circuits after a number of guard node failures have + been experienced. + + Unfortunately, we believe that this is not a sufficiently strong + countermeasure since puzzled users will not comprehend the + confusing warning message about guard node failures and they will + instead just uninstall and reinstall TBB to fix the issue. + +2.5. What this proposal does not propose + + Finally, this proposal does not aim to solve all the problems with + guard nodes. This proposal only tries to solve some of the problems + whose solution is analyzed sufficiently and seems harmless enough + to us. + + For example, this proposal does not try to solve: + - Guard enumeration attacks. We need guard layers or virtual + circuits for this [6]. + - The guard node set fingerprinting problem [7] + - The fact that each isolation profile or virtual identity should + have its own guards. + +XXX It would also be nice to have some way to easily revert back to 3 + guards if we later decide that a single guard was a very stupid + idea. + +References: + +[0]: https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-pa… + http://freehaven.net/anonbib/#wpes12-cogs + +[1]: https://blog.torproject.org/blog/lifecycle-of-a-new-relay + +[2]: https://lists.torproject.org/pipermail/tor-dev/2014-March/006458.html + +[3]: https://trac.torproject.org/projects/tor/ticket/9273#comment:4 + +[4]: http://freehaven.net/anonbib/#pets13-splitting + +[5]: https://blog.torproject.org/blog/new-tor-denial-service-attacks-and-defenses + +[6]: https://trac.torproject.org/projects/tor/ticket/9001 + +[7]: https://trac.torproject.org/projects/tor/ticket/10969 +

1 0

[torspec/master] Add Nick's name in the authors and delete some trailing whitespace.
by nickm＠torproject.org 23 Apr '14

23 Apr '14

commit c91b4cc7bd6067e31c969633cf520b1555eccbb9 Author: George Kadianakis <desnacked(a)riseup.net> Date: Tue Apr 22 17:20:08 2014 +0300 Add Nick's name in the authors and delete some trailing whitespace. --- proposals/xxx-single-guard-node.txt | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/proposals/xxx-single-guard-node.txt b/proposals/xxx-single-guard-node.txt index f47735f..451b483 100644 --- a/proposals/xxx-single-guard-node.txt +++ b/proposals/xxx-single-guard-node.txt @@ -1,6 +1,6 @@ Filename: xxx-single-guard-node.txt Title: The move to a single guard node -Author: George Kadianakis +Author: George Kadianakis, Nicholas Hopper Created: 2014-03-22 Status: Draft @@ -38,8 +38,8 @@ Status: Draft A Guard node is considered unusable according to section "5. Guard nodes" in path-spec.txt. The rest of the rules from that section apply here too. XXX which rules specifically? -asn - XXX Probably the rules about how to add a new guard (only after - contact), when to re-try a guard for reachability, and when to + XXX Probably the rules about how to add a new guard (only after + contact), when to re-try a guard for reachability, and when to discard a guard? -nickhopper XXX Do we need to specify how already existing clients migrate? @@ -112,13 +112,13 @@ Status: Draft where NNN is the number of months in the guard rotation period (10 months if this proposal is adopted in full) and calculates the visibility of the guard; that is, in how many consensuses it has - had the guard flag. + had the guard flag. The authorities include the age of each guard by appending '[SP "GV=" INT]' in the guard's "w" line. A guard N that has been visible for V out of NNN*30*24 consensuses - has had the opportunity to be chosen as a guard by approximately + has had the opportunity to be chosen as a guard by approximately F = V/NNN*30*24 of the clients in the network, and the remaining 1-F fraction of the clients have not noticed this change. So when being chosen for middle or exit positions on a circuit, clients @@ -284,4 +284,3 @@ References: [6]: https://trac.torproject.org/projects/tor/ticket/9001 [7]: https://trac.torproject.org/projects/tor/ticket/10969 -

1 0

[torspec/master] Merge remote-tracking branch 'asn/single_guard'
by nickm＠torproject.org 23 Apr '14

23 Apr '14

commit 54e352497d08eb55bcce1f81e7b12a6e66e99957 Merge: 78de0f9 c91b4cc Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Apr 23 14:19:18 2014 -0400 Merge remote-tracking branch 'asn/single_guard' proposals/xxx-single-guard-node.txt | 286 +++++++++++++++++++++++++++++++++++ 1 file changed, 286 insertions(+)

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits April 2014