tor-commits December 2019

tor-commits@lists.torproject.org

21 participants
1811 discussions

[translation/donatepages-messagespot] https://gitweb.torproject.org/translation.git/commit/?h=donatepages-messagespot
by translation＠torproject.org 14 Dec '19

14 Dec '19

commit 189f238c93e372cf955c822ec31d78433046fcfa Author: Translation commit bot <translation(a)torproject.org> Date: Sat Dec 14 12:45:35 2019 +0000 https://gitweb.torproject.org/translation.git/commit/?h=donatepages-message… --- locale/ro/LC_MESSAGES/messages.po | 25 ++++++++++++++++++++++--- 1 file changed, 22 insertions(+), 3 deletions(-) diff --git a/locale/ro/LC_MESSAGES/messages.po b/locale/ro/LC_MESSAGES/messages.po index 23be54f29b..be2ac6fcbc 100644 --- a/locale/ro/LC_MESSAGES/messages.po +++ b/locale/ro/LC_MESSAGES/messages.po @@ -888,10 +888,12 @@ msgid "" "Checks</a> or <a class=\"hyperlinks links\" href=\"/%langcode%/donor-faq" "#donate-anonymous\">Money Orders</a>" msgstr "" +"Cecuri</a> sau <a class=\"hyperlinks links\" href=\"/%langcode%/donor-faq" +"#donate-anonymous\">Ordine de Plată</a>" #: tmp/cache_locale/7d/7d56367a61f987367eeb2a89d0c6db83fd0801cce86278bf7e99ed39b5b46254.php:138 msgid "Stock Donation" -msgstr "" +msgstr "Donație de bunuri" #: tmp/cache_locale/7d/7d56367a61f987367eeb2a89d0c6db83fd0801cce86278bf7e99ed39b5b46254.php:143 msgid "" @@ -1386,6 +1388,9 @@ msgid "" "href=\"https://renewablefreedom.org/contact/\" target=\"_blank\" " "class=\"hyperlinks links\">upon request</a>." msgstr "" +"Aceștia vor emite un bon de donație <a " +"href=\"https://renewablefreedom.org/contact/\" target=\"_blank\" " +"class=\"hyperlinks links\">la cerere</a>." #: tmp/cache_locale/7d/7d56367a61f987367eeb2a89d0c6db83fd0801cce86278bf7e99ed39b5b46254.php:349 msgid "The account information is as follows:" @@ -2091,6 +2096,9 @@ msgid "" "stickers, are presented on our main <a class=\"hyperlinks links\" " "href=\"/%langcode%\">donation page</a>." msgstr "" +"O varietate de cadouri de mulțumire pentru donatori, inclusiv tricouri, " +"hanorace și autocolante, sunt prezentate pe <a class=\"hyperlinks links\" " +"href=\"/%langcode%\">pagina noastră principală de donație</a>." #: tmp/cache_locale/7d/7d56367a61f987367eeb2a89d0c6db83fd0801cce86278bf7e99ed39b5b46254.php:721 msgid "" @@ -2128,10 +2136,14 @@ msgid "" "target=\"_blank\" class=\"hyperlinks links\">King County Employee Giving " "Program</a>." msgstr "" +"Tor este configurat să participe la <a " +"href=\"https://www.kingcounty.gov/audience/employees/giving.aspx\" " +"target=\"_blank\" class=\"hyperlinks links\">Programul King County Employee " +"Giving." #: tmp/cache_locale/7d/7d56367a61f987367eeb2a89d0c6db83fd0801cce86278bf7e99ed39b5b46254.php:737 msgid "Tor doesn't currently participate in the Federal CFC program." -msgstr "" +msgstr "Tor nu participă în prezent la programul Federal CFC." #: tmp/cache_locale/7d/7d56367a61f987367eeb2a89d0c6db83fd0801cce86278bf7e99ed39b5b46254.php:739 msgid "" @@ -2164,6 +2176,10 @@ msgid "" "to make a hardware donation that you think might be especially useful for " "us, please mail <span class=\"email\">giving(at)torproject.org</span>." msgstr "" +"De obicei nu încurajăm oamenii să doneze echipamente hardware. Dar dacă " +"doriți să faceți o donație hardware care credeți că ar putea fi utilă în " +"special pentru noi, vă rugăm să ne trimiteți un e-mail la <span " +"class=\"email\">giving(at)torproject.org</span>." #: tmp/cache_locale/7d/7d56367a61f987367eeb2a89d0c6db83fd0801cce86278bf7e99ed39b5b46254.php:767 msgid "Can I donate my time?" @@ -2175,6 +2191,9 @@ msgid "" "href=\"https://community.torproject.org\">list of areas where we would love " "your help</a>." msgstr "" +"Iată o <a class=\"hyperlinks links\" target=\"_blank\" " +"href=\"https://community.torproject.org\">listă cu domeniile în care am dori" +" ajutorul tău</a>." #: tmp/cache_locale/7d/7d56367a61f987367eeb2a89d0c6db83fd0801cce86278bf7e99ed39b5b46254.php:779 msgid "I would like my company to support Tor." @@ -2205,7 +2224,7 @@ msgid "" "Maybe your company would be willing to <a class=\"hyperlinks links\" " "target=\"_blank\" href=\"https://community.torproject.org/relay/\">operate a" " Tor relay</a>." -msgstr "" +msgstr "Poate compania dvs. ar fi dispusă să administreze un releu Tor</a>." #: tmp/cache_locale/7d/7d56367a61f987367eeb2a89d0c6db83fd0801cce86278bf7e99ed39b5b46254.php:791 msgid ""

1 0

[translation/support-portal] https://gitweb.torproject.org/translation.git/commit/?h=support-portal
by translation＠torproject.org 14 Dec '19

14 Dec '19

commit d0973d3bac13902bcb5a24acd1fe016188fa1a05 Author: Translation commit bot <translation(a)torproject.org> Date: Sat Dec 14 11:54:36 2019 +0000 https://gitweb.torproject.org/translation.git/commit/?h=support-portal --- contents+ar.po | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/contents+ar.po b/contents+ar.po index 32909b986e..e74e3865aa 100644 --- a/contents+ar.po +++ b/contents+ar.po @@ -738,7 +738,7 @@ msgstr "هذا ينشأ تصميما بسيطا سهل الإستخدام." #: https//support.torproject.org/about/how-is-tor-different-from-other-proxies/ #: (content/about/how-is-tor-different-from-other-proxies/contents+en.lrquestion.description) msgid "The users all enter and leave through the same server." -msgstr "" +msgstr "كل المستخدمين يدخلون و برحلون من نفس الخادوم." #: https//support.torproject.org/about/how-is-tor-different-from-other-proxies/ #: (content/about/how-is-tor-different-from-other-proxies/contents+en.lrquestion.description) @@ -746,11 +746,13 @@ msgid "" "The provider may charge for use of the proxy, or fund their costs through " "advertisements on the server." msgstr "" +"مزود الخدمة من الممكن أن يخصل رسوما على استخدام البروكسى، او يقوم بتغطية " +"نكاليفه عن طريق الإعلانات على الخادوم." #: https//support.torproject.org/about/how-is-tor-different-from-other-proxies/ #: (content/about/how-is-tor-different-from-other-proxies/contents+en.lrquestion.description) msgid "In the simplest configuration, you don't have to install anything." -msgstr "" +msgstr "فى أبسط تهيئة ليس عليك تثبيت أى شىء." #: https//support.torproject.org/about/how-is-tor-different-from-other-proxies/ #: (content/about/how-is-tor-different-from-other-proxies/contents+en.lrquestion.description)

1 0

[translation/support-portal] https://gitweb.torproject.org/translation.git/commit/?h=support-portal
by translation＠torproject.org 14 Dec '19

14 Dec '19

commit 85c4e0d7423c23850bc2955e72a877154af56e77 Author: Translation commit bot <translation(a)torproject.org> Date: Sat Dec 14 11:24:36 2019 +0000 https://gitweb.torproject.org/translation.git/commit/?h=support-portal --- contents+ar.po | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/contents+ar.po b/contents+ar.po index e1470e9b54..32909b986e 100644 --- a/contents+ar.po +++ b/contents+ar.po @@ -685,6 +685,9 @@ msgid "" "Public License](https://www.fsf.org/licensing/licenses/gpl.html), while " "Firefox ESR is released under the Mozilla Public License." msgstr "" +"كلا من امتدادي فَيَرْفُكْسْ يتم توزيعهم برخصة [رخصة GNU " +"العمومية](https://www.fsf.org/licensing/licenses/gpl.html)، بينما اصدار " +"فَيَرْفُكْسْ ذو الدعم الممتد يتم اصداره برخصة Mozilla العامة." #: https//support.torproject.org/about/distribute-tor/ #: (content/about/distribute-tor/contents+en.lrquestion.description) @@ -692,6 +695,8 @@ msgid "" "The simplest way to obey their licenses is to include the source code for " "these programs everywhere you include the bundles themselves." msgstr "" +"الطريقة الأسهل لاتباع رخصهم هى أن تتضمن رمز المصدر لهذه البرامج فى كل مكان " +"تتضمن فيه هذه البرامج." #: https//support.torproject.org/about/distribute-tor/ #: (content/about/distribute-tor/contents+en.lrquestion.description) @@ -699,6 +704,8 @@ msgid "" "Also, you should make sure not to confuse your readers about what Tor is, " "who makes it, and what properties it provides (and doesn't provide)." msgstr "" +"أيضا يجب عليك أن لا تسبب أى لبس لقرائك عن ماهية Tor، ومن الذى عمله، وما " +"الخصائص التى يوفرها (والتى لا يوفرها)." #: https//support.torproject.org/about/distribute-tor/ #: (content/about/distribute-tor/contents+en.lrquestion.description) @@ -706,11 +713,13 @@ msgid "" "See our [trademark FAQ](https://www.torproject.org/about/trademark/) for " "details." msgstr "" +"انظر إلى [الأسئلة الشائعة عن العلامة " +"المسجلة](https://www.torproject.org/about/trademark/) للتفاصيل." #: https//support.torproject.org/about/how-is-tor-different-from-other-proxies/ #: (content/about/how-is-tor-different-from-other-proxies/contents+en.lrquestion.title) msgid "How is Tor different from other proxies?" -msgstr "" +msgstr "ما هو الفرق بين Tor و البروكسيهات الأخرى؟" #: https//support.torproject.org/about/how-is-tor-different-from-other-proxies/ #: (content/about/how-is-tor-different-from-other-proxies/contents+en.lrquestion.description) @@ -718,11 +727,13 @@ msgid "" "A typical proxy provider sets up a server somewhere on the Internet and " "allows you to use it to relay your traffic." msgstr "" +"مزود خدمة البروكسى العادية يقوم بضبط خادوم فى مكان ما على الإنترنت و يسمح لك" +" باستخدامه لاعادة بث مرورك." #: https//support.torproject.org/about/how-is-tor-different-from-other-proxies/ #: (content/about/how-is-tor-different-from-other-proxies/contents+en.lrquestion.description) msgid "This creates a simple, easy to maintain architecture." -msgstr "" +msgstr "هذا ينشأ تصميما بسيطا سهل الإستخدام." #: https//support.torproject.org/about/how-is-tor-different-from-other-proxies/ #: (content/about/how-is-tor-different-from-other-proxies/contents+en.lrquestion.description)

1 0

[translation/support-portal] https://gitweb.torproject.org/translation.git/commit/?h=support-portal
by translation＠torproject.org 14 Dec '19

14 Dec '19

commit 1103286cfe978f22c409ae788bf391726ef2f820 Author: Translation commit bot <translation(a)torproject.org> Date: Sat Dec 14 10:54:52 2019 +0000 https://gitweb.torproject.org/translation.git/commit/?h=support-portal --- contents+ar.po | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/contents+ar.po b/contents+ar.po index 8bc31b1d37..e1470e9b54 100644 --- a/contents+ar.po +++ b/contents+ar.po @@ -9,6 +9,7 @@ # ButterflyOfFire, 2019 # Emma Peel, 2019 # Layla Taha <layla(a)asl19.org>, 2019 +# Ahmed Essam, 2019 # msgid "" msgstr "" @@ -16,7 +17,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2019-11-14 16:04+CET\n" "PO-Revision-Date: 2018-10-02 22:41+0000\n" -"Last-Translator: Layla Taha <layla(a)asl19.org>, 2019\n" +"Last-Translator: Ahmed Essam, 2019\n" "Language-Team: Arabic (https://www.transifex.com/otf/teams/1519/ar/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -645,6 +646,8 @@ msgid "" "Essentially this means that you need to include our LICENSE file along with " "whatever part of the Tor software you're distributing." msgstr "" +"هذا معناه بالأساس أن تضمن ملف الرخصة الخاص بنا مع أى جزء من Tor تقوم " +"بتوزيعه." #: https//support.torproject.org/about/distribute-tor/ #: (content/about/distribute-tor/contents+en.lrquestion.description) @@ -652,11 +655,13 @@ msgid "" "Most people who ask us this question don't want to distribute just the Tor " "software, though." msgstr "" +"على أية حال، أغلب الناس الذين يسألونا هذا السؤال لا يريدون فقط توزيع برنامج " +"Tor." #: https//support.torproject.org/about/distribute-tor/ #: (content/about/distribute-tor/contents+en.lrquestion.description) msgid "They want to distribute the Tor Browser." -msgstr "" +msgstr "يريدون توزيع المتصفح Tor Browser." #: https//support.torproject.org/about/distribute-tor/ #: (content/about/distribute-tor/contents+en.lrquestion.description) @@ -665,11 +670,13 @@ msgid "" "US/firefox/organizations/), and the NoScript and HTTPS-Everywhere " "extensions." msgstr "" +"هذا يتضمن [اصدار فَيَرْفُكْسْ ذو الدعم الممتد](https://www.mozilla.org/en-" +"US/firefox/organizations/)، وامتدادات NoScript وHTTPS-Everywhere." #: https//support.torproject.org/about/distribute-tor/ #: (content/about/distribute-tor/contents+en.lrquestion.description) msgid "You will need to follow the license for those programs as well." -msgstr "" +msgstr "سوف تحتاج إلى اتباع رخص هذه البرامج أيضا." #: https//support.torproject.org/about/distribute-tor/ #: (content/about/distribute-tor/contents+en.lrquestion.description)

1 0

[tor-browser-build/master] Bug 32751: Sign incrementals sha256sums too if var/sign_build is set
by gk＠torproject.org 14 Dec '19

14 Dec '19

commit adf23abdceb488864de0639fc74affd3556eb2fc Author: Nicolas Vigier <boklm(a)torproject.org> Date: Fri Dec 13 17:12:23 2019 +0100 Bug 32751: Sign incrementals sha256sums too if var/sign_build is set --- README | 10 +++++----- projects/release/hash_incrementals | 3 +++ rbm.local.conf.example | 5 +++-- 3 files changed, 11 insertions(+), 7 deletions(-) diff --git a/README b/README index d77a460..5dbf77e 100644 --- a/README +++ b/README @@ -155,11 +155,11 @@ Signing builds -------------- If the environment variable RBM_SIGN_BUILD is set to 1, the -sha256sums-unsigned-build.txt file will be signed with gpg. -You can use the RBM_GPG_OPTS environment variable to add some options -to the gpg command used to sign the file. You can also set the -var/sign_build and var/sign_build_gpg_opts options in the rbm.local.conf -file. +sha256sums-unsigned-build.txt and sha256sums-unsigned-build.incrementals.txt +files will be signed with gpg. You can use the RBM_GPG_OPTS environment +variable to add some options to the gpg command used to sign the file. +You can also set the var/sign_build and var/sign_build_gpg_opts options +in the rbm.local.conf file. Cleaning obsolete files and containers images diff --git a/projects/release/hash_incrementals b/projects/release/hash_incrementals index ba95ac7..cf31bfd 100644 --- a/projects/release/hash_incrementals +++ b/projects/release/hash_incrementals @@ -6,3 +6,6 @@ cd [% shell_quote(path(dest_dir)) %]/[% c("var/signed_status") %]/[% c("version") %]-[% c("var/torbrowser_build") %] [% END -%] sha256sum `ls -1 | grep '\.incremental\.mar$' | sort` > sha256sums-[% c("var/signed_status") %]-build.incrementals.txt +[% IF c("var/sign_build") -%] + gpg -abs [% c("var/sign_build_gpg_opts") %] sha256sums-[% c("var/signed_status") %]-build.incrementals.txt +[% END -%] diff --git a/rbm.local.conf.example b/rbm.local.conf.example index dc3f038..dd59034 100644 --- a/rbm.local.conf.example +++ b/rbm.local.conf.example @@ -45,12 +45,13 @@ var: local_conf: 1 ### The var/sign_build option defines if you want to sign the - ### sha256sums-unsigned-build.txt file with gpg. + ### sha256sums-unsigned-build.txt and + ### sha256sums-unsigned-build.incrementals.txt files with gpg. #sign_build: 1 ### The var/sign_build_gpg_opts option can be used to define some gpg ### options to select the key to use to sign the sha256sums-unsigned-build.txt - ### file. + ### and sha256sums-unsigned-build.incrementals.txt files. #sign_build_gpg_opts: '--local-user XXXXXXXX' ### The clean configuration is used by the cleaning script to find the

1 0

[translation/tails-misc_release] https://gitweb.torproject.org/translation.git/commit/?h=tails-misc_release
by translation＠torproject.org 14 Dec '19

14 Dec '19

commit 2bc0a3ccc4ae4ea70dd9f575d0d40804f8b644cc Author: Translation commit bot <translation(a)torproject.org> Date: Sat Dec 14 00:19:11 2019 +0000 https://gitweb.torproject.org/translation.git/commit/?h=tails-misc_release --- nl.po | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/nl.po b/nl.po index 74959dd5d8..3a83f9afb0 100644 --- a/nl.po +++ b/nl.po @@ -18,9 +18,9 @@ # kwadronaut <kwadronaut(a)autistici.org>, 2017-2019 # LittleNacho <louisboy(a)msn.com>, 2013 # 53a60eabbf5124a226a7678001f9a57b, 2015 -# Meteor 0id, 2019 +# Meteor0id, 2019 # Nathan Follens, 2015 -# Meteor 0id, 2019 +# Meteor0id, 2019 # Midgard, 2014 # T. Des Maison <ton.siedsma(a)bof.nl>, 2014 # Thinkwell, 2018

1 0

[snowflake/master] proxy/make.js: add help output
by dcf＠torproject.org 13 Dec '19

13 Dec '19

commit 37aaaffa1521b4ff6166a2a013d8e6e5c6e8fbce Author: Jascha <jascha(a)jaeh.at> Date: Fri Dec 13 04:47:50 2019 +0100 proxy/make.js: add help output --- proxy/make.js | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/proxy/make.js b/proxy/make.js index f8b2192..6111913 100755 --- a/proxy/make.js +++ b/proxy/make.js @@ -192,4 +192,10 @@ if (tasks.has(cmd)) { t.func(); } else { console.error('Command not supported.'); + + console.log('Commands:'); + + tasks.forEach(function(value, key) { + console.log(key + ' - ' + value.msg); + }) }

1 0

[torspec/master] fix line endings on prop 307
by arma＠torproject.org 13 Dec '19

13 Dec '19

commit 54346bf40f5509505f154d6137370ee882522920 Author: Roger Dingledine <arma(a)torproject.org> Date: Fri Dec 13 15:44:44 2019 -0500 fix line endings on prop 307 (whoever committed it, committed it with a bonus ^M on each line) --- proposals/307-onionbalance-v3.txt | 364 +++++++++++++++++++------------------- 1 file changed, 182 insertions(+), 182 deletions(-) diff --git a/proposals/307-onionbalance-v3.txt b/proposals/307-onionbalance-v3.txt index 6ff0ca4..9a66c69 100644 --- a/proposals/307-onionbalance-v3.txt +++ b/proposals/307-onionbalance-v3.txt @@ -1,182 +1,182 @@ -Filename: 307-onionbalance-v3.txt -Title: Onion Balance Support for Onion Service v3 -Author: Nick Mathewson -Created: 03-April-2019 -Status: Draft - -0. Draft Notes - - 2019-07-25: - - At this point in time, the cross-certification is not implemented - correctly in >= tor-0.3.2.1-alpha. See https://trac.torproject.org/29583 - for more details. - - This proposal assumes that this bug is fixed. - -1. Introduction - - The OnionBalance tool allows several independent Tor instances to host an - onion service, while clients can access that onion service without having - to take its distributed status into account. OnionBalance works by having - each instance run a separate onion service. Then, a management server - periodically downloads the descriptors from those onion services, and - generates a new descriptor containing the introduction points from each - instance's onion service. - - OnionBalance is used by several high-profile onion services, including - Facebook and The Tor Project. - - Unfortunately, because of the cross-certification features in v3 onion - services, OnionBalance no longer works for them. To a certain extent, this - breakage is because of a security improvement: It's probably a good thing - that random third parties can no longer grab a onion service's introduction - points and claim that they are introduction points for a different service. - But nonetheless, a lack of a working OnionBalance remains an obstacle for - v3 onion service migration. - - This proposal describes extensions to v3 onion service design to - accommodate OnionBalance. - -2. Background and Solution - - If an OnionBalance management server wants to provide an aggregate - descriptor for a v3 onion service, it faces several obstacles that it - didn't have in v2. - - When the management server goes to construct an aggregated descriptor, it - will have a mismatch on the "auth-key", "enc-key-cert", and - "legacy-key-cert" fields: these fields are supposed to certify the onion - service's current descriptor-signing key, but each of these keys will be - generated independently by each instance. Because they won't match each - other, there is no possible key that the aggregated descriptor could use - for its descriptor signing key. - - In this design, we require that each instance should know in advance about - a descriptor-signing public key that the aggregate descriptor will use for - each time period. (I'll explain how they can do this later, in section 3 - below.) They don't have to know the corresponding private key. - - When generating their own onion service descriptors for a given time - period, the instances generate these additional fields to be used for the - aggregate descriptor: - - "meta-auth-key" - "meta-enc-key-cert" - "meta-legacy-key-cert" - - These fields correspond to "auth-key", "enc-key-cert", and - "legacy-key-cert" respectively, but differ in one regard: the - descriptor-signing public key that they certify is _not_ the instance's own - descriptor-signing key, but rather the aggregate public key for the time - period. - - Ordinary clients ignore these new fields. - - When the management server creates the aggregate descriptor, it checks that - the signing key for each of these "meta" fields matches the signing key for - its corresponding non-"meta" field, and that they certify the correct - descriptor-signing key-- and then uses these fields in place of their - corresponding non-"meta" variants. - -2.1. A quick note on synchronization - - In the design above, and in the section below, I frequently refer to "the - current time period". By this, I mean the time period for which the - descriptor is encoded, not the time period in which it is generated. - - Instances and management servers should generate descriptors for the two - closest time periods, as they do today: no additional synchronization - should needed here. - -3. How to distribute descriptor-signing keys - - The design requires that every instance of the onion service knows about - the public descriptor-signing key that will be used for the aggregate onion - service. Here I'll discuss how this can be achieved. - -3.1. If the instances are trusted. - - If the management server trusts each of the instances, it can distribute a - shared secret to each one of them, and use this shared secret to derive - each time period's private key. - - For example, if the shared secret is SK, then the private descriptor- - signing key for each time period could be derived as: - - H("meta-descriptor-signing-key-deriv" | - onion_service_identity - INT_8(period_num) | - INT_8(period_length) | - SK ) - - (Remember that in the terminology of rend-spec-v3, INT_8() denotes a 64-bit - integer, see section 0.2 in rend-spec-v3.txt.) - - If shared secret is ever compromised, then an attacker can impersonate the - onion service until the shared secret is changed, and can correlate all - past descriptors for the onion service. - -3.2. If the instances are not trusted: Option One - - If the management server does not trust the instances with - descriptor-signing public keys, another option for it is to simply - distribute a load of public keys in advance, and use them according to a - schedule. - - In this design, the management server would pre-generate the - "descriptor-signing-key-cert" fields for a long time in advance, and - distribute them to the instances offline. Each one would be - associated with its corresponding time period. - - If these certificates were revealed to an attacker, the attacker - could correlate descriptors for the onion service with one another, - but could not impersonate the service. - -3.3. If the instances are not trusted: Option Two - - Another option for the trust model of 3.2 above is to use the same - key-blinding method as used for v3 onion services. The management server - would hold a private descriptor-signing key, and use it to derive a - different private descriptor-signing key for each time period. The instance - servers would hold the corresponding public key, and use it to derive a - different public descriptor-signing key for each time period. - - (For security, the key-blinding function in this case should use a - different nonce than used in the) - - This design would allow the instances to only be configured once, which - would be simpler than 3.2 above-- but at a cost. The management server's - use of a long-term private descriptor-signing key would require it to keep - that key online. (It could keep the derived private descriptor-signing keys - online, but the parent key could be derived from them.) - - Here, if the instance's knowledge were revealed to an attack, the attacker - could correlate descriptors for the onion service with one another, but - could not impersonate the service. - -4. Some features of this proposal - - We retain the property that each instance service remains accessible as a - working onion service. However, anyone who can access it can identify it as - an instance of an OnionBalance service, and correlate its descriptor to the - aggregate descriptor. - - Instances could use client authorization to ensure that only the management - server can decrypt their introduction points. However, because of the - key-blinding features of v3 onion services, nobody who doesn't know the - onion addresses for the instances can access them anyway: It would be - sufficient to keep these addresses secret. - - Although anybody who successfully accesses an instance can correlate its - descriptor to the meta-descriptor, this only works for two descriptors - within a single time period: You can't match an instance descriptor from - one time period to a meta-descriptor from another. - -A. Acknowledgments - - Thanks to the network team for helping me clarify my ideas here, explore - options, and better understand some of the implementations and challenges - in this problem space. - - This research was supported by NSF grants CNS-1526306 and CNS-1619454. +Filename: 307-onionbalance-v3.txt +Title: Onion Balance Support for Onion Service v3 +Author: Nick Mathewson +Created: 03-April-2019 +Status: Draft + +0. Draft Notes + + 2019-07-25: + + At this point in time, the cross-certification is not implemented + correctly in >= tor-0.3.2.1-alpha. See https://trac.torproject.org/29583 + for more details. + + This proposal assumes that this bug is fixed. + +1. Introduction + + The OnionBalance tool allows several independent Tor instances to host an + onion service, while clients can access that onion service without having + to take its distributed status into account. OnionBalance works by having + each instance run a separate onion service. Then, a management server + periodically downloads the descriptors from those onion services, and + generates a new descriptor containing the introduction points from each + instance's onion service. + + OnionBalance is used by several high-profile onion services, including + Facebook and The Tor Project. + + Unfortunately, because of the cross-certification features in v3 onion + services, OnionBalance no longer works for them. To a certain extent, this + breakage is because of a security improvement: It's probably a good thing + that random third parties can no longer grab a onion service's introduction + points and claim that they are introduction points for a different service. + But nonetheless, a lack of a working OnionBalance remains an obstacle for + v3 onion service migration. + + This proposal describes extensions to v3 onion service design to + accommodate OnionBalance. + +2. Background and Solution + + If an OnionBalance management server wants to provide an aggregate + descriptor for a v3 onion service, it faces several obstacles that it + didn't have in v2. + + When the management server goes to construct an aggregated descriptor, it + will have a mismatch on the "auth-key", "enc-key-cert", and + "legacy-key-cert" fields: these fields are supposed to certify the onion + service's current descriptor-signing key, but each of these keys will be + generated independently by each instance. Because they won't match each + other, there is no possible key that the aggregated descriptor could use + for its descriptor signing key. + + In this design, we require that each instance should know in advance about + a descriptor-signing public key that the aggregate descriptor will use for + each time period. (I'll explain how they can do this later, in section 3 + below.) They don't have to know the corresponding private key. + + When generating their own onion service descriptors for a given time + period, the instances generate these additional fields to be used for the + aggregate descriptor: + + "meta-auth-key" + "meta-enc-key-cert" + "meta-legacy-key-cert" + + These fields correspond to "auth-key", "enc-key-cert", and + "legacy-key-cert" respectively, but differ in one regard: the + descriptor-signing public key that they certify is _not_ the instance's own + descriptor-signing key, but rather the aggregate public key for the time + period. + + Ordinary clients ignore these new fields. + + When the management server creates the aggregate descriptor, it checks that + the signing key for each of these "meta" fields matches the signing key for + its corresponding non-"meta" field, and that they certify the correct + descriptor-signing key-- and then uses these fields in place of their + corresponding non-"meta" variants. + +2.1. A quick note on synchronization + + In the design above, and in the section below, I frequently refer to "the + current time period". By this, I mean the time period for which the + descriptor is encoded, not the time period in which it is generated. + + Instances and management servers should generate descriptors for the two + closest time periods, as they do today: no additional synchronization + should needed here. + +3. How to distribute descriptor-signing keys + + The design requires that every instance of the onion service knows about + the public descriptor-signing key that will be used for the aggregate onion + service. Here I'll discuss how this can be achieved. + +3.1. If the instances are trusted. + + If the management server trusts each of the instances, it can distribute a + shared secret to each one of them, and use this shared secret to derive + each time period's private key. + + For example, if the shared secret is SK, then the private descriptor- + signing key for each time period could be derived as: + + H("meta-descriptor-signing-key-deriv" | + onion_service_identity + INT_8(period_num) | + INT_8(period_length) | + SK ) + + (Remember that in the terminology of rend-spec-v3, INT_8() denotes a 64-bit + integer, see section 0.2 in rend-spec-v3.txt.) + + If shared secret is ever compromised, then an attacker can impersonate the + onion service until the shared secret is changed, and can correlate all + past descriptors for the onion service. + +3.2. If the instances are not trusted: Option One + + If the management server does not trust the instances with + descriptor-signing public keys, another option for it is to simply + distribute a load of public keys in advance, and use them according to a + schedule. + + In this design, the management server would pre-generate the + "descriptor-signing-key-cert" fields for a long time in advance, and + distribute them to the instances offline. Each one would be + associated with its corresponding time period. + + If these certificates were revealed to an attacker, the attacker + could correlate descriptors for the onion service with one another, + but could not impersonate the service. + +3.3. If the instances are not trusted: Option Two + + Another option for the trust model of 3.2 above is to use the same + key-blinding method as used for v3 onion services. The management server + would hold a private descriptor-signing key, and use it to derive a + different private descriptor-signing key for each time period. The instance + servers would hold the corresponding public key, and use it to derive a + different public descriptor-signing key for each time period. + + (For security, the key-blinding function in this case should use a + different nonce than used in the) + + This design would allow the instances to only be configured once, which + would be simpler than 3.2 above-- but at a cost. The management server's + use of a long-term private descriptor-signing key would require it to keep + that key online. (It could keep the derived private descriptor-signing keys + online, but the parent key could be derived from them.) + + Here, if the instance's knowledge were revealed to an attack, the attacker + could correlate descriptors for the onion service with one another, but + could not impersonate the service. + +4. Some features of this proposal + + We retain the property that each instance service remains accessible as a + working onion service. However, anyone who can access it can identify it as + an instance of an OnionBalance service, and correlate its descriptor to the + aggregate descriptor. + + Instances could use client authorization to ensure that only the management + server can decrypt their introduction points. However, because of the + key-blinding features of v3 onion services, nobody who doesn't know the + onion addresses for the instances can access them anyway: It would be + sufficient to keep these addresses secret. + + Although anybody who successfully accesses an instance can correlate its + descriptor to the meta-descriptor, this only works for two descriptors + within a single time period: You can't match an instance descriptor from + one time period to a meta-descriptor from another. + +A. Acknowledgments + + Thanks to the network team for helping me clarify my ideas here, explore + options, and better understand some of the implementations and challenges + in this problem space. + + This research was supported by NSF grants CNS-1526306 and CNS-1619454.

1 0

[translation/communitytpo-contentspot] https://gitweb.torproject.org/translation.git/commit/?h=communitytpo-contentspot
by translation＠torproject.org 13 Dec '19

13 Dec '19

commit a3d1d39e5f118181f1b8e05299611eeed472868b Author: Translation commit bot <translation(a)torproject.org> Date: Fri Dec 13 20:45:29 2019 +0000 https://gitweb.torproject.org/translation.git/commit/?h=communitytpo-conten… --- contents+ka.po | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/contents+ka.po b/contents+ka.po index 8a3a59d50b..e6ab666d41 100644 --- a/contents+ka.po +++ b/contents+ka.po @@ -252,22 +252,22 @@ msgstr "" #: https//community.torproject.org/outreach/ #: (content/outreach/contents+en.lrpage.title) msgid "Outreach" -msgstr "" +msgstr "გავრცელება" #: https//community.torproject.org/outreach/ #: (content/outreach/contents+en.lrpage.subtitle) msgid "Bring Tor materials to your next community event." -msgstr "" +msgstr "მიაწოდეთ Tor-ის მასალები თქვენს ერთობას, მომდევნო შეხვედრებისას." #: https//community.torproject.org/outreach/ #: (content/outreach/contents+en.lrpage.cta) msgid "Tell the world about Tor" -msgstr "" +msgstr "მოუყევით მსოფლიოს Tor-ზე" #: https//community.torproject.org/outreach/ #: (content/outreach/contents+en.lrpage.body) msgid "##Tell the world about Tor" -msgstr "" +msgstr "##აცნობეთ მსოფლიოს Tor-ის შესახებ" #: https//community.torproject.org/outreach/ #: (content/outreach/contents+en.lrpage.body)

1 0

[torspec/master] add nsf acks to four proposals
by arma＠torproject.org 13 Dec '19

13 Dec '19

commit a51495cdd71ba0eed72f57eb02274761ce95f7e0 Author: Roger Dingledine <arma(a)torproject.org> Date: Fri Dec 13 15:44:01 2019 -0500 add nsf acks to four proposals --- proposals/300-walking-onions.txt | 2 ++ proposals/302-padding-machines-for-onion-clients.txt | 4 ++++ proposals/305-establish-intro-dos-defense-extention.txt | 4 ++++ proposals/307-onionbalance-v3.txt | 2 ++ 4 files changed, 12 insertions(+) diff --git a/proposals/300-walking-onions.txt b/proposals/300-walking-onions.txt index 0192c2e..ece0c0a 100644 --- a/proposals/300-walking-onions.txt +++ b/proposals/300-walking-onions.txt @@ -499,6 +499,8 @@ A.1. Acknowledgments Thanks to David Goulet, Teor, and George Kadianakis for commentary on earlier versions of this draft. + This research was supported by NSF grants CNS-1526306 and CNS-1619454. + A.2. Additional ideas Teor notes that there are ways to try to get this idea to apply to diff --git a/proposals/302-padding-machines-for-onion-clients.txt b/proposals/302-padding-machines-for-onion-clients.txt index 4123e85..cd24298 100644 --- a/proposals/302-padding-machines-for-onion-clients.txt +++ b/proposals/302-padding-machines-for-onion-clients.txt @@ -291,6 +291,10 @@ NOTE: Please look at section 3 of padding-spec.txt now, not this document. circuits, and also what other classifiers can be built using deep learning and whatnot. +A. Acknowledgements + + This research was supported by NSF grants CNS-1526306 and CNS-1619454. + --- [0]: https://www.usenix.org/node/190967 diff --git a/proposals/305-establish-intro-dos-defense-extention.txt b/proposals/305-establish-intro-dos-defense-extention.txt index a0ddcef..e377f3e 100644 --- a/proposals/305-establish-intro-dos-defense-extention.txt +++ b/proposals/305-establish-intro-dos-defense-extention.txt @@ -191,6 +191,10 @@ Status: Closed or very popular which could mean time to increase or disable the denial of service defenses. +A. Acknowledgements + + This research was supported by NSF grants CNS-1526306 and CNS-1619454. + References: [1] https://lists.torproject.org/pipermail/tor-dev/2019-May/013837.html diff --git a/proposals/307-onionbalance-v3.txt b/proposals/307-onionbalance-v3.txt index 8716f13..6ff0ca4 100644 --- a/proposals/307-onionbalance-v3.txt +++ b/proposals/307-onionbalance-v3.txt @@ -178,3 +178,5 @@ A. Acknowledgments Thanks to the network team for helping me clarify my ideas here, explore options, and better understand some of the implementations and challenges in this problem space. + + This research was supported by NSF grants CNS-1526306 and CNS-1619454.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits December 2019