September 2019 - tor-commits - lists.torproject.org

[translation/orfox-stringsxml] https://gitweb.torproject.org/translation.git/commit/?h=orfox-stringsxml
by translation＠torproject.org 06 Sep '19

06 Sep '19

commit 79c96898d09075c9cc25e323b05bc81ad9726f9b Author: Translation commit bot <translation(a)torproject.org> Date: Fri Sep 6 13:46:46 2019 +0000 https://gitweb.torproject.org/translation.git/commit/?h=orfox-stringsxml --- nl/strings.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/nl/strings.xml b/nl/strings.xml index ea44aad3a..a3f69ba86 100644 --- a/nl/strings.xml +++ b/nl/strings.xml @@ -6,4 +6,5 @@ <string name="go_to_f_droid">NAAR F-DROID</string> <string name="go_to_google_play">NAAR GOOGLE PLAY</string> <string name="download_apk">.APK DOWNLOADEN</string> - </resources> + <string name="export_bookmarks">Bladwijzers exporteren</string> +</resources>

1 0

[gettor/master] Update playbooks and add role for web
by hiro＠torproject.org 06 Sep '19

06 Sep '19

commit f9b6a7ad33046e29c4d9113ab7fdd79cfb995315 Author: hiro <hiro(a)torproject.org> Date: Fri Sep 6 14:46:59 2019 +0200 Update playbooks and add role for web --- playbooks/group_vars/all.yml | 2 ++ playbooks/update.yml | 1 + roles/gettor-web/tasks/main.yml | 35 +++++++++++++++++++++++++++++++++++ roles/gettor/tasks/main.yml | 4 ++-- 4 files changed, 40 insertions(+), 2 deletions(-) diff --git a/playbooks/group_vars/all.yml b/playbooks/group_vars/all.yml index beb08b7..5a4c58f 100644 --- a/playbooks/group_vars/all.yml +++ b/playbooks/group_vars/all.yml @@ -1,3 +1,5 @@ --- gettor_repo: https://git.torproject.org/gettor.git gettor_path: /srv/gettor.torproject.org/home/gettor +gettor_web_path: /srv/gettor.torproject.org/home/gettor-web +home_path: /srv/gettor.torproject.org/home/ diff --git a/playbooks/update.yml b/playbooks/update.yml index 08534e4..1b08808 100644 --- a/playbooks/update.yml +++ b/playbooks/update.yml @@ -3,3 +3,4 @@ - gettor roles: - gettor + - gettor-web diff --git a/roles/gettor-web/tasks/main.yml b/roles/gettor-web/tasks/main.yml new file mode 100644 index 0000000..8d383de --- /dev/null +++ b/roles/gettor-web/tasks/main.yml @@ -0,0 +1,35 @@ +--- +- name: check if repository exists + stat: + path: "{{ gettor_web_path }}/.git/config" + register: stat_result + +- name: update gettor source + git: + repo: https://git.torproject.org/project/web/gettor-web.git + version: master + dest: /srv/gettor.torproject.org/home/gettor-web/ + clone: no + update: yes + +- name: create virtualenv + command: > + virtualenv {{ gettor_path }}/venv + args: + chdir: "{{ gettor_path }}" + +- pip: + name: lektor + virtualenv: {{ gettor_web_path }}/venv + +- name: activate virtualenv + command: . {{ gettor_web_path }}/venv/bin/activate + +- name: lektor build + command: lektor build -O {{ home_path }}/www + +- name: update static component + command: > + static-update-component gettor.torproject.org + args: + chdir: "{{ gettor_web_path }}" diff --git a/roles/gettor/tasks/main.yml b/roles/gettor/tasks/main.yml index b56b288..89298f4 100644 --- a/roles/gettor/tasks/main.yml +++ b/roles/gettor/tasks/main.yml @@ -23,11 +23,11 @@ chdir: "{{ gettor_path }}" - name: activate virtualenv - command: . { gettor_path }}/venv/bin/activate + command: . {{ gettor_path }}/venv/bin/activate - name: create database command: > - {{ gettor_path }}/venv/bin/python3 {{ gettor_path }}/scripts/create_db -n -c -o + {{ gettor_path }}/venv/bin/python3 {{ gettor_path }}/scripts/create_db -n -c -o -f gettor.db - name: add links command: >

1 0

[gettor-web/master] Add information to CONTRIBUTING
by hiro＠torproject.org 06 Sep '19

06 Sep '19

commit 2907594011688afd59b9b4b2ea9e969685a9ecf6 Author: hiro <hiro(a)torproject.org> Date: Fri Sep 6 14:35:16 2019 +0200 Add information to CONTRIBUTING --- CONTRIBUTING.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e69de29..bc562ca 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -0,0 +1,5 @@ +This is a lektor generated website. + +All the content can be found in the `content/` folder. + +Please see https://dip.torproject.org/web/tpo/wikis/home for more information about how to develop on a lektor website and our styleguide.

1 0

[gettor-web/master] Add README.md
by hiro＠torproject.org 06 Sep '19

06 Sep '19

commit 3387902d2d96d3476525291124eb115a890d3cfa Author: Gaba E <gaba(a)torproject.org> Date: Thu May 23 22:55:26 2019 +0000 Add README.md --- README.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/README.md b/README.md new file mode 100644 index 0000000..0dc7dec --- /dev/null +++ b/README.md @@ -0,0 +1,3 @@ +# README + +Gettor web \ No newline at end of file

1 0

[gettor-web/master] Add CONTRIBUTING
by hiro＠torproject.org 06 Sep '19

06 Sep '19

commit d115a90a82836c52fac41e7c4e47ff518414f99b Author: Gaba E <gaba(a)torproject.org> Date: Thu May 23 22:56:14 2019 +0000 Add CONTRIBUTING --- CONTRIBUTING.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..e69de29

1 0

[gettor-web/master] Update instructions for gettor
by hiro＠torproject.org 06 Sep '19

06 Sep '19

commit ab39ffcbcb134f0ec2398afdec07a6d55a1c31a9 Author: hiro <hiro(a)torproject.org> Date: Fri Sep 6 14:26:48 2019 +0200 Update instructions for gettor --- assets/javascript | 2 +- assets/scss | 2 +- assets/static/css | 2 +- assets/static/fonts | 2 +- assets/static/js | 2 +- content/contents.lr | 122 +++++++++++++++++++++++++++++++++++++++++++++++----- lego | 2 +- 7 files changed, 118 insertions(+), 16 deletions(-) diff --git a/assets/javascript b/assets/javascript index c8db05e..f1da3c5 120000 --- a/assets/javascript +++ b/assets/javascript @@ -1 +1 @@ -../lego/assests/javascript \ No newline at end of file +../lego/assets/javascript \ No newline at end of file diff --git a/assets/scss b/assets/scss index b77f409..2d8ed2e 120000 --- a/assets/scss +++ b/assets/scss @@ -1 +1 @@ -../lego/assests/scss \ No newline at end of file +../lego/assets/scss \ No newline at end of file diff --git a/assets/static/css b/assets/static/css index 0db4948..12e4567 120000 --- a/assets/static/css +++ b/assets/static/css @@ -1 +1 @@ -../../lego/assests/static/css \ No newline at end of file +../../lego/assets/static/css \ No newline at end of file diff --git a/assets/static/fonts b/assets/static/fonts index 2da38c7..25deee7 120000 --- a/assets/static/fonts +++ b/assets/static/fonts @@ -1 +1 @@ -../../lego/assests/static/fonts \ No newline at end of file +../../lego/assets/static/fonts \ No newline at end of file diff --git a/assets/static/js b/assets/static/js index 7b741e3..361859a 120000 --- a/assets/static/js +++ b/assets/static/js @@ -1 +1 @@ -../../lego/assests/static/js \ No newline at end of file +../../lego/assets/static/js \ No newline at end of file diff --git a/content/contents.lr b/content/contents.lr index 5afa18c..f7b79bf 100644 --- a/content/contents.lr +++ b/content/contents.lr @@ -5,22 +5,124 @@ body: GetTor is a service that provides alternative methods to download the Tor Browser, especially for people living in places with high levels of censorship, where access to Tor Project's website is restricted. -### How does it work? +# How does it work? The idea behind GetTor is very simple: -Step 1: Send a request to GetTor specifying your operating system (and optionally your locale). +- Step 1: Send a request to GetTor (gettor(a)torproject.org) specifying your operating system (and your locale). Ex: "windows es" -Step 2: GetTor will send you back a reply with links to download Tor Browser from our supported providers. +- Step 2: GetTor will send you back a reply with links to download Tor Browser from our supported providers. -Step 3: Download Tor Browser from one of the providers. When done, check the integrity of the downloaded files. +- Step 3: Download Tor Browser from one of the providers. When done, check the integrity of the downloaded files by verifying its signature. -Step 4: If required, get some bridges! +- Step 4: If required, get some bridges! -### Channels -You can make requests to GetTor using different channels of communication and different locales. At the present moment, we support the following locales: English (en), Farsi (fa), Chinese (zh), Turkish (tr), and the following channels: -Email: you can make a request sending an email to gettor(a)torproject.org +## How to verify a digital signature -Quick example: -To get links for downloading Tor Browser in English for Windows, send an email to gettor(a)torproject.org with the words "windows en" in the body of the message. +Digital signature is a process ensuring that a certain package was generated by its developers and has not been tampered with. +Below we explain why it is important and how to verify that the Tor program you download is the one we have created and has not been modified by some attacker. + +In GetTor emails we provide a link to a file with the same name as the package and the extension ".asc". These .asc files are OpenPGP signatures. +They allow you to verify the file you've downloaded is exactly the one that we intended you to get. +For example, `torbrowser-install-win64-8.5.4_en-US.exe` is accompanied by `torbrowser-install-win64-8.5.4_en-US.exe.asc`. + +We now show how you can verify the downloaded file's digital signature on different operating systems. +Please notice that a signature is dated the moment the package has been signed. +Therefore every time a new file is uploaded a new signature is generated with a different date. +As long as you have verified the signature you should not worry that the reported date may vary. + +### Installing GnuPG + +First of all you need to have GnuPG installed before you can verify signatures. + +#### For Windows users: + +If you run Windows, [download Gpg4win](https://gpg4win.org/download.html) and run its installer. + +In order to verify the signature you will need to type a few commands in windows command-line, `cmd.exe`. + +#### For macOS users: + +If you are using macOS, you can [install GPGTools](https://www.gpgtools.org). + +In order to verify the signature you will need to type a few commands in the Terminal (under "Applications"). + +#### For GNU/Linux users: + +If you are using GNU/Linux, then you probably already have GnuPG in your system, as most GNU/Linux distributions come with it preinstalled. + +In order to verify the signature you will need to type a few commands in a terminal window. How to do this will vary depending on your distribution. + +### Fetching the Tor Developers key + +The Tor Browser team signs Tor Browser releases. +Import the Tor Browser Developers signing key (0xEF6E286DDA85EA2A4BA7DE684E2C6E8793298290): + + gpg --auto-key-locate nodefault,wkd --locate-keys torbrowser(a)torproject.org + +This should show you something like: + + gpg: key 4E2C6E8793298290: public key "Tor Browser Developers (signing key) <torbrowser(a)torproject.org>" imported + gpg: Total number processed: 1 + gpg: imported: 1 + pub rsa4096 2014-12-15 [C] [expires: 2020-08-24] + EF6E286DDA85EA2A4BA7DE684E2C6E8793298290 + uid [ unknown] Tor Browser Developers (signing key) <torbrowser(a)torproject.org> + sub rsa4096 2018-05-26 [S] [expires: 2020-09-12] + +After importing the key, you can save it to a file (identifying it by fingerprint here): + + gpg --output ./tor.keyring --export 0xEF6E286DDA85EA2A4BA7DE684E2C6E8793298290 + +### Verifying the signature + +To verify the signature of the package you downloaded, you will need to download the corresponding ".asc" signature file as well as the installer file itself, and verify it with a command that asks GnuPG to verify the file that you downloaded. + +The examples below assume that you downloaded these two files to your "Downloads" folder. + +The result of the command should produce something like this: + + gpgv: Signature made 07/08/19 04:03:49 Pacific Daylight Time + gpgv: using RSA key EB774491D9FF06E2 + gpgv: Good signature from "Tor Browser Developers (signing key) <torbrowser(a)torproject.org>" + + +#### For Windows users: + + gpgv --keyring .\tor.keyring Downloads\torbrowser-install-win64-8.5.4_en-US.exe.asc Downloads\torbrowser-install-win64-8.5.4_en-US.exe + +#### For macOS users: + + gpgv --keyring ./tor.keyring ~/Downloads/TorBrowser-8.5.4-osx64_en-US.dmg{.asc,} + +#### For GNU/Linux users (change 64 to 32 if you have the 32-bit package): + + gpgv --keyring ./tor.keyring tor-browser-linux64-8.5.4_en-US.tar.xz{.asc,} + + +You may also want to [learn more about GnuPG](https://www.gnupg.org/documentation/). + + +## How to get bridges + +Bridge relays are Tor relays that are not listed in the public Tor directory. +That means that ISPs or governments trying to block access to the Tor network can't simply block all bridges. +Bridges are useful for Tor users under oppressive regimes, and for people who want an extra layer of security because they're worried somebody will recognize that they are contacting a public Tor relay IP address. + +When you start TorBrowser for the first time you will be asked if you want to use bridges. To use pluggable transports, click 'Configure' in the Tor Launcher window that appears when you first run Tor Browser. + +You can also configure pluggable transports while Tor Browser is running by clicking on the onion icon to the left of the address bar, then selecting 'Tor Network Settings'. + +Select 'Tor is censored in my country,' then click 'Select a built-in bridge.' Click on the drop-down menu and select the pluggable transport you'd like to use. + +Click 'OK' to save your settings. + +Another way to get bridges is to send an email to bridges(a)torproject.org. Please note that you must send the email using an address from one of the following email providers: Riseup or Gmail. + +A bridge is just a normal relay with a slightly different configuration. + +Several countries, including China and Iran, have found ways to detect and block connections to Tor bridges. +<mark><a href="https://github.com/Yawning/obfs4/blob/master/doc/obfs4-spec.txt">Obfsproxy</a></mark> bridges address this by adding another layer of obfuscation. +Setting up an obfsproxy bridge requires an additional software package and additional configurations. +See our page on <mark><a href="https://www.torproject.org/docs/pluggable-transports.html.en">pluggable transports</a></mark> for more info. diff --git a/lego b/lego index 9e6fd6b..094dd93 160000 --- a/lego +++ b/lego @@ -1 +1 @@ -Subproject commit 9e6fd6b34b8252ad3cc0a8eb81e640320c2ba6b8 +Subproject commit 094dd93359d24f87c74eaa932de7f3214dd93333

1 0

[torspec/master] Add proposal 307 (onionbalance for v3 onion services)
by nickm＠torproject.org 06 Sep '19

06 Sep '19

commit 09611eaf46028f0610824412c547f9450ff81bc5 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Sep 6 08:02:46 2019 -0400 Add proposal 307 (onionbalance for v3 onion services) --- proposals/000-index.txt | 2 + proposals/307-onionbalance-v3.txt | 180 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 182 insertions(+) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 2c3c620..69ae099 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -227,6 +227,7 @@ Proposals by number: 304 Extending SOCKS5 Onion Service Error Codes [ACCEPTED] 305 ESTABLISH_INTRO Cell DoS Defense Extension [DRAFT] 306 A Tor Implementation of IPv6 Happy Eyeballs [OPEN] +307 Onion Balance Support for Onion Service v3 [DRAFT] Proposals by status: @@ -238,6 +239,7 @@ Proposals by status: 300 Walking Onions: Scaling and Saving Bandwidth 303 When and how to remove support for protocol versions 305 ESTABLISH_INTRO Cell DoS Defense Extension + 307 Onion Balance Support for Onion Service v3 NEEDS-REVISION: 212 Increase Acceptable Consensus Age [for 0.2.4.x+] 219 Support for full DNS and DNSSEC resolution in Tor [for 0.2.5.x] diff --git a/proposals/307-onionbalance-v3.txt b/proposals/307-onionbalance-v3.txt new file mode 100644 index 0000000..8716f13 --- /dev/null +++ b/proposals/307-onionbalance-v3.txt @@ -0,0 +1,180 @@ +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.

1 0

[torspec/master] Merge branch 'prop306_squashed'
by nickm＠torproject.org 06 Sep '19

06 Sep '19

commit 2e89f93aee97016c17377a84ac46ea50f286acc8 Merge: 87698dc a4c0cd1 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Sep 6 08:00:09 2019 -0400 Merge branch 'prop306_squashed' proposals/306-ipv6-happy-eyeballs.txt | 300 ++++++++++++++++++++++++++++++++++ 1 file changed, 300 insertions(+)

1 0

[torspec/master] Add Proposal 306: A Tor Implementation of IPv6 Happy Eyeballs
by nickm＠torproject.org 06 Sep '19

06 Sep '19

commit a4c0cd1a4f1921823b896026858e683191597496 Author: Neel Chauhan <neel(a)neelc.org> Date: Tue Jun 25 21:10:19 2019 -0400 Add Proposal 306: A Tor Implementation of IPv6 Happy Eyeballs --- proposals/306-ipv6-happy-eyeballs.txt | 300 ++++++++++++++++++++++++++++++++++ 1 file changed, 300 insertions(+) diff --git a/proposals/306-ipv6-happy-eyeballs.txt b/proposals/306-ipv6-happy-eyeballs.txt new file mode 100644 index 0000000..a096384 --- /dev/null +++ b/proposals/306-ipv6-happy-eyeballs.txt @@ -0,0 +1,300 @@ +Filename: 306-ipv6-happy-eyeballs.txt +Title: A Tor Implementation of IPv6 Happy Eyeballs +Author: Neel Chauhan +Created: 25-Jun-2019 +Supercedes: 299 +Status: Open +Ticket: https://trac.torproject.org/projects/tor/ticket/29801 + +1. Introduction + + As IPv4 address space becomes scarce, ISPs and organizations will deploy + IPv6 in their networks. Right now, Tor clients connect to guards using + IPv4 connectivity by default. + + When networks first transition to IPv6, both IPv4 and IPv6 will be enabled + on most networks in a so-called "dual-stack" configuration. This is to not + break existing IPv4-only applications while enabling IPv6 connectivity. + However, IPv6 connectivity may be unreliable and clients should be able + to connect to the guard using the most reliable technology, whether IPv4 + or IPv6. + + In ticket #27490, we introduced the option ClientAutoIPv6ORPort which + lets a client randomly choose between IPv4 or IPv6. However, this + random decision does not take into account unreliable connectivity + or falling back to the competing IP version should one be unreliable + or unavailable. + + One way to select between IPv4 and IPv6 on a dual-stack network is a + so-called "Happy Eyeballs" algorithm as per RFC 8305. In one, a client + attempts the preferred IP family, whether IPv4 or IPv6. Should it work, + the client sticks with the preferred IP family. Otherwise, the client + attempts the alternate version. This means if a dual-stack client has + both IPv4 and IPv6, and IPv6 is unreliable, preferred or not, the + client uses IPv4, and vice versa. However, if IPv4 and IPv6 are both + equally reliable, and IPv6 is preferred, we use IPv6. + + In Proposal 299, we have attempted a IP fallback mechanism using failure + counters and preferring IPv4 and IPv6 based on the state of the counters. + However, Prop299 was not standard Happy Eyeballs and an alternative, + standards-compliant proposal was requested in [P299-TRAC] to avoid issues + from complexity caused by randomness. + + This proposal describes a Tor implementation of Happy Eyeballs and is + intended as a successor to Proposal 299. + +2. Address/Relay Selection + + This section describes the necessary changes for address selection to + implement Prop306. + +2.1. Extend Info Structure Changes + + To be able to handle Happy Eyeballs in Tor, we will need to modify the + data structures used for connections to guards, namely the extend info + structure. + + The extend info structure should contain both an IPv4 and an IPv6 address. + This will allow us to try IPv4 and the IPv6 addresses should both be + available on a relay and the client is dual-stack. + + When parsing relay descriptors and filling in the extend info data + structure, we need to fill in both the IPv4 and IPv6 address if they both + are available. If only one family is available for a relay (IPv4 or IPv6), + we should fill in the address for preferred family and leave the alternate + family null. + +2.2. Relay Selection Changes + + In Proposal 283, we have allowed microdescriptor consensus documents to + contain IPv6 addresses. As clients download microdescriptors, Prop283 + makes it possible to implement Prop306. + + When we select candidates for the entry guard, we should select at least + one relay with an IPv6 address. This makes it possible for an IPv6-only + client to bootstrap. Otherwise we would have failures if all the selected + guard candidates only have IPv4 addresses. + +3. Relay Connections + + If there is an existing authenticated connection, we should use it + similar to how we used it pre-Prop306. + + If there is no existing authenticated connection for an extend info, + we should attempt to connect using the first available, allowed, and + preferred address. + + We should also allow falling back to the alternate address. For this, + three alternate designs will be given. + +3.1. Proposed Designs + + This subsection will have three proposed designs for connecting to relays + via IPv4 and IPv6 in a Tor implementation of Happy Eyeballs. + + These proposed designs will have some tradeoffs, including: + + * Launching multiple TCP connections places up to 2x extra socket load on + dual-stack relays and authorities, because both connections may succeed. + + * Launching multiple TLS connections places up to 2x the CPU load on + dual-stack relays and authorities, because both connections may succeed. + + * Increasing the delay between connections mitigates the above issues, + but reduces perceived performance, particularly at bootstrap time + (pre-emptive circuits hide these delays after bootstrap). + + The proposed designs are as listed as follows: + + * Section 3.1.1: First Successful Authentication + + * Section 3.1.2: TCP Connection to Preferred Address On First Authenticated + Connection + + * Section 3.1.3: TCP Connection to Preferred Address On First TCP Success + +3.1.1. First Successful Authentication + + In this design, Tor will first connect to the preferred address and + attempt to authenticate. After a 1.5 second delay (based on Onionperf + data), Tor will connect to the alternate address and try to authenticate. + On the first successful authenticated connection, we close the other + connection. + + This design places the least connection load on the network, but might + add extra TLS load. + +3.1.2. TCP Connection to Preferred Address On First Authenticated Connection + + This design attempts a TCP connection to a preferred address. On a failure + or a 1.5 second delay, we try the alternative address. + + On the first successful TCP connection Tor attempts to authenticate + immediately. On the first authentication success, Tor closes the other + connection. + + This design is the most reliable for clients, but increases the connection + load on dual-stack guards and authorities. For instance, this can be used + to amplify a DoS attack on the Tor network. + +3.1.3. TCP Connection to Preferred Address On First TCP Success + + In this design, we will connect via TCP to the first preferred address. On + a failure or after a 1.5 second delay, we attempt to connect via TCP to the + alternate address. On a success, Tor attempts to authenticate and closes + the other connection. + + This design is the closest to RFC 8305 and is similar to how Happy Eyeballs + is implemented in a web browser. + +3.2. Recommendations for Implementation of Section 3.1 Proposals + + We should start with implementing and testing the implementation as + described in Section 3.1.1 (First Successful Authentication), and then + doing the same for the implementations described in 3.1.2 and 3.1.3 if + desired or required. + +3.3. Handling Connection Successes And Failures + + Should a connection to a guard succeed and is authenticated via TLS, we + can then use the connection. In this case, we should cancel all other + connection timers and in-progress connections. Cancelling the timers is + necessary so we don't attempt new unnecessary connections when our + existing connection is successful, preventing denial-of-service risks. + + However, if we fail all available and allowed connections, we should tell + the rest of Tor that the connection has failed. This is so we can attempt + another guard relay. + +3.4. Connection Attempt Delays + + As mentioned in [TEOR-P306-REP], initially, clients should prefer IPv4 + by default. The Connection Attempt Delay, or delay between IPv4 and IPv6 + connections should be 1.5 seconds. This is to avoid the overhead from + tunneled IPv6 connections. + + The Minimum Connection Attempt Delay should not be dynamically adjusted + as it adds privacy risks. This value should be fixed at 10 ms as per + RFC 8305 and could be adjusted using a proposed consensus parameter called + ConnectionAttemptDelay. ConnectionAttemptDelay should be in milliseconds. + + The Maximum Connection Attempt Delay should also not be dynamically adjusted + for privacy reasons, but the maximum should be higher than the RFC 8305 + recommendation of 2 seconds. For Tor, we should make this timeout value 30 + seconds to match Tor's existing timeout. + + We should also make it possible for users to set the Maximum Connection + Attempt value higher for slower and higher-latency networks such as dial-up + and satellite. + +4. Option Changes + + As we enable IPv6-enabled clients to connect out of the box, we should + adjust the default options to enable IPv6 while not breaking IPv4-only + clients. + +4.1. New Default Options for Prop306 + + The new default options should be: + + * ClientUseIPv4 as 1 (to enable IPv4) + + * ClientUseIPv6 as 1 (to enable IPv6) + + * ClientPreferIPv6ORPort as 0 (for load-balancing reasons so we don't + overload IPv6-only guards) + + One thing to note is that clients should be able to connect with the above + options on IPv4-only, dual-stack, and IPv6-only networks, and they should + also work if ClientPreferIPv6ORPort is 1. This means we shouldn't expect + IPv4 or IPv6 to work if ClientUseIPv4 or ClientUseIPv6 is set. + + When the majority of clients are IPv6-capable, we could set the default + value of ClientPreferIPv6ORPort to 1 in order to take advantage of IPv6. + +4.2. Prop306 Consensus Parameters + + We could have the following consensus parameters: + + * ClientUseIPv6 + + * ClientPreferIPv6ORPort (when most of the guards have IPv6 and it is fast) + + Should we have the consenus parameters, the values for these options should + be set to the values of the similarly-named options as described in Section + 4.1 including the consideration for ClientPreferIPv6ORPort. + +5. Statistics + +5.1. Relay Statistics + + Relays could measure the number of successful IPv4 and IPv6 connections. + We could also send this information to directory authorities. + + However, should we implement Section 5.1, we should consider the privacy + implications of these statistics, and whether they should be public or not. + +5.2. Client Heartbeat Messages + + In a Tor session, we should count the number of IPv4 and IPv6 connections + to ORPorts, and distinguish between authenticated (relay, authority + reachability) and unauthenticated (client, bridge) connections. These + statistics should be included in the Heartbeat logs. + +6. Deploying Prop306 + + This section describes the information necessary for deployment of Prop306 + on Tor clients and in Tor Browser. + +6.1. Initial Feasibility Testing + + We should test this proposal with the following scenarios: + + * Different combinations of values for the options ClientUseIPv4, + ClientUseIPv6, and ClientPreferIPv6ORPort on IPv4-only, IPv6-only, + and dual-stack connections + + * Dual-stack connections of different technologies, including high-bandwidth + and low-latency (e.g. fiber), moderate-bandwidth and moderate-latency + (e.g. DSL, LTE), and high-latency and low-bandwidth (e.g. satellite, + dial-up) to see if Prop306 is reliable and feasible + +6.2. Minimum Viable Prop306 Product + + The mimumum viable product for Prop306 must include the following: + + * Implementation of one of the algorithms in Section 3.1 along with the + changes described in Sections 2.1 and 2.2 + + * The Connection Success/Failure mechanism in Section 3.3 and Connection + Delay mechanism in Section 3.4 (the consensus parameter is optional) + + * A default setup capable of both IPv4 and IPv6 connections with the + options described in Section 4.1 + +6.3. Optional Features + + Some features which are optional include: + + * Consensus Parameter ConnectionAttemptDelay (Section 3.4) - We will need + this if the Minimum Connection Attempt Delay needs to be dynamically + adjusted + + * Consensus Parameters ClientUseIPv6 (Section 4.2), and + ClientPreferIPv6ORPort (Section 4.2) - We will need this if we desire + the ability for clients to prefer IPv6 when the majority of clients + and relays are IPv6-capable without changing the configuration + + * Prop306 Statistics (Section 5) - While optional, this may be useful for + debugging and reliability testing, and metrics on IPv4 vs. IPv6 + +7. Acknowledgments + + Thank you so much to teor for the discussion of the happy eyeballs proposal. + I wouldn't have been able to do this has it not been for your help. + +8. Refrences + + [P299-TRAC]: https://trac.torproject.org/projects/tor/ticket/29801 + + [TEOR-P306-REP]: https://lists.torproject.org/pipermail/tor-dev/2019-July/013919.html

1 0

[torspec/master] Add proposal 306 to the index
by nickm＠torproject.org 06 Sep '19

06 Sep '19

commit 013e51649fb6760c08aa6d7dfd7442cd41d5c827 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Sep 6 08:00:27 2019 -0400 Add proposal 306 to the index --- proposals/000-index.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 728c53d..2c3c620 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -226,6 +226,7 @@ Proposals by number: 303 When and how to remove support for protocol versions [DRAFT] 304 Extending SOCKS5 Onion Service Error Codes [ACCEPTED] 305 ESTABLISH_INTRO Cell DoS Defense Extension [DRAFT] +306 A Tor Implementation of IPv6 Happy Eyeballs [OPEN] Proposals by status: @@ -259,6 +260,7 @@ Proposals by status: 295 Using ADL for relay cryptography (solving the crypto-tagging attack) 296 Have Directory Authorities expose raw bandwidth list files 299 Preferring IPv4 or IPv6 based on IP Version Failure Count + 306 A Tor Implementation of IPv6 Happy Eyeballs ACCEPTED: 188 Bridge Guards and other anti-enumeration defenses 249 Allow CREATE cells with >505 bytes of handshake data

1 0