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

[community/develop] better strings for l10n. please add one sentence per line.
by pili＠torproject.org 18 Nov '19

18 Nov '19

commit d8e9c59d9311e93045db94c491a8615523a33bf8 Author: emma peel <emma.peel(a)riseup.net> Date: Thu Oct 31 15:41:39 2019 +0100 better strings for l10n. please add one sentence per line. --- content/user-research/contents.lr | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/content/user-research/contents.lr b/content/user-research/contents.lr index 2ad1aeb..31b93ef 100644 --- a/content/user-research/contents.lr +++ b/content/user-research/contents.lr @@ -20,4 +20,7 @@ body: ## We respect our users' privacy when we conduct research. -We practice human-centered design when we build tools for internet freedom. The way we build tools also builds community. Our user research is founded on the premises of consent, respect, and empathy. You can make an impact in your community by learning from our methods and helping us with user research. +We practice human-centered design when we build tools for internet freedom. +The way we build tools also builds community. +Our user research is founded on the premises of consent, respect, and empathy. +You can make an impact in your community by learning from our methods and helping us with user research.

1 0

[community/develop] Improve docker setup instructions.
by pili＠torproject.org 18 Nov '19

18 Nov '19

commit bfe821bc6466793d8cffdec579b43df219dd28e5 Author: Philipp Winter <phw(a)nymity.ch> Date: Wed Oct 30 12:35:29 2019 -0700 Improve docker setup instructions. This partially fixes: <https://bugs.torproject.org/31834> --- .../technical-setup/bridge/docker/contents.lr | 50 +++++++++++++++++++--- 1 file changed, 44 insertions(+), 6 deletions(-) diff --git a/content/relay-operations/technical-setup/bridge/docker/contents.lr b/content/relay-operations/technical-setup/bridge/docker/contents.lr index f82a65e..f401b1e 100644 --- a/content/relay-operations/technical-setup/bridge/docker/contents.lr +++ b/content/relay-operations/technical-setup/bridge/docker/contents.lr @@ -6,17 +6,55 @@ title: Docker --- body: -We are maintaining a docker container that allows you to quickly set up an obfs4 bridge. First, fetch the container: +We are maintaining a docker container that runs an obfs4 bridge. This guide +walks you through setting up this container. First, download the container: -`docker pull phwinter/obfs4-bridge:latest` +``` +docker pull phwinter/obfs4-bridge:latest +``` -Now, it's time to run the container. We maintain a script that automatically determines a free OR and obfs4 port for you. The script only requires your email address as argument: +Now, it's time to run the container. You can choose between two options: + +1. We maintain a script that determines a free OR and obfs4 port for you, and + then runs the docker container. + [Download the script here](https://dip.torproject.org/torproject/anti-censorship/docker-obfs4-br…. + When running this script, provide your email address as argument: + ``` + bash deploy-container.sh address(a)email.com ``` - $ curl https://dip.torproject.org/torproject/anti-censorship/docker-obfs4-bridge/r… > deploy-container.sh - $ bash deploy-container.sh address(a)email.com + The script will tell you what ports it chose, and your container ID. Make + sure that **both** ports are forwarded in your firewall. + +2. If you would rather provide your own ports, run the following command and + replace `XXX` with your OR port, `YYY` with your obfs4 port, and + `admin(a)example.com` with your email address. + ``` + OR_PORT=XXX PT_PORT=YYY EMAIL=admin(a)example.com; docker run -d -e OR_PORT=$OR_PORT -e PT_PORT=$PT_PORT -e EMAIL=$EMAIL -p $OR_PORT:$OR_PORT -p $PT_PORT:$PT_PORT phwinter/obfs4-bridge:latest + ``` + + Again, make sure that **both** ports are forwarded by your firewall. + +That's it! Your container should now be bootstrapping your new obfs4 bridge. +You can inspect its logs by running: + +``` +docker logs CONTAINER_ID +``` + +To use your new bridge in Tor Browser, you need its "bridge line". Here's how +you can get your bridge line: + +``` +docker exec CONTAINER_ID get-bridge-line +``` + +This will return a string similar to the following: + +``` +obfs4 1.2.3.4:1234 B0E566C9031657EA7ED3FC9D248E8AC4F37635A4 cert=OYWq67L7MDApdJCctUAF7rX8LHvMxvIBPHOoAp0+YXzlQdsxhw6EapaMNwbbGICkpY8CPQ iat-mode=0 +``` -That's it! Your container should now be bootstrapping your new obfs4 Tor bridge. Make sure to check out the [post-install notes](https://community.torproject.org/relay/setup/bridge/post-install/). If you are having troubles setting up your bridge, have a look at [our help

1 0

[community/develop] Fix spelling mistakes and improve phrasing.
by pili＠torproject.org 18 Nov '19

18 Nov '19

commit f0439f0b1cec908bd8222eee1da79c32987abdca Author: Philipp Winter <phw(a)nymity.ch> Date: Tue Nov 12 08:58:14 2019 -0800 Fix spelling mistakes and improve phrasing. --- .../technical-setup/exit/contents.lr | 36 +++++++++++----------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/content/relay-operations/technical-setup/exit/contents.lr b/content/relay-operations/technical-setup/exit/contents.lr index ee0148c..43d6f39 100644 --- a/content/relay-operations/technical-setup/exit/contents.lr +++ b/content/relay-operations/technical-setup/exit/contents.lr @@ -60,29 +60,29 @@ ExitRelay 1 ## DNS on Exit Relays Unlike other types of relays, exit relays also do DNS resolution for Tor clients. -DNS resolution on exit relays is crucial for Tor clients, it should be reliable and fast by using caching. +DNS resolution on exit relays is crucial for Tor clients and it should be reliable and fast by using caching. -* DNS resolution can have a significant impact on the performance and reliability your exit relay provides. - Poor DNS performance will result in less traffic going through your exit relay. -* Don't use any of the big DNS resolvers as your primary or fallback DNS resolver to avoid centralization (Google, OpenDNS, Quad9, Cloudflare, 4.2.2.1-6) -* We recommend running a local caching and DNSSEC-validating resolver without using any forwarders (specific instructions follow bellow for each operating systems) - * If you want to add a second DNS resolver as a fallback to your /etc/resolv.conf configuration, try to choose a resolver within your autonomous system and make sure it is not your first entry in that file (the first entry should be your local resolver) - * If a local resolver like unbound is not an option for you try to use a resolver that your provider runs in the same autonomous system (to find out if an IP address is in the same AS as your relay, you can look it up, using for example https://bgp.he.net) -* Try to avoid adding too many resolvers to your /etc/resolv.conf file to limit exposure on an AS-level (try to not use more than two entries) +* DNS resolution can have a significant impact on the performance and reliability that your exit relay provides. +* Don't use any of the big DNS resolvers (Google, OpenDNS, Quad9, Cloudflare, 4.2.2.1-6) as your primary or fallback DNS resolver to avoid centralization. +* We recommend running a local caching and DNSSEC-validating resolver without using any forwarders (specific instructions follow below, for various operating systems). + * If you want to add a second DNS resolver as a fallback to your /etc/resolv.conf configuration, choose a resolver within your autonomous system and make sure that it is not your first entry in that file (the first entry should be your local resolver). + * If a local resolver like unbound is not an option for you, use a resolver that your provider runs in the same autonomous system (to find out if an IP address is in the same AS as your relay, you can look it up using [bgp.he.net](https://bgp.he.net)). +* Avoid adding more than two resolvers to your /etc/resolv.conf file to limit AS-level exposure of DNS queries. -There are multiple options for DNS server software, unbound has become a popular one but **feel free to use any other you are comfortable with**. -When choosing your DNS resolver software try to ensure it supports DNSSEC validation and QNAME minimisation (RFC7816). -In every case the software should be installed using the OS package manager to ensure it is updated with the rest of the system. +There are multiple options for DNS server software. [Unbound](https://nlnetlabs.nl/projects/unbound/about/) has become +a popular one but feel free to use any other software that you are comfortable with. +When choosing your DNS resolver software, make sure that it supports DNSSEC validation and QNAME minimization (RFC7816). +Install the resolver software over your operating system's package manager, to ensure that it is updated automatically. -By using your own DNS resolver you are less vulnerable to DNS-based censorship that your upstream resolver might impose. +By using your own DNS resolver, you are less vulnerable to DNS-based censorship that your upstream resolver might impose. -Here follow specific instructions on how to install and configure unbound on your exit - a DNSSEC-validating and caching resolver. unbound has many configuration and tuning nobs but we try to keep these instructions as simple and short as possible and the basic setup will do just fine for most operators. +Below are instructions on how to install and configure unbound – a DNSSEC-validating and caching resolver – on your exit relay. Unbound has many configuration and tuning knobs but we keep these instructions simple and short; the basic setup will do just fine for most operators. -After switching to unbound verify it works as expected by resolving a valid hostname, if it does not work, you can restore the old resolv.conf file. +After switching to unbound, verify it works as expected by resolving a valid hostname. If it does not work, you can restore your old resolv.conf file. ### Debian/Ubuntu -The following 3 commands install unbound, backup your DNS configuration and tell the system to use the local unbound: +The following three commands install unbound, backup your DNS configuration, and tell the system to use the local unbound: ``` apt install unbound @@ -96,8 +96,8 @@ To avoid that the configuration gets changed (for example by the DHCP client): chattr +i /etc/resolv.conf ``` -The Debian configuration ships with QNAME minimisation (RFC7816) enabled by default so you don't need to enable it explicitly. -The unbound resolver you just installed does also DNSSEC validation. +The Debian configuration ships with QNAME minimization (RFC7816) enabled by default, so you don't need to enable it explicitly. +The unbound resolver you just installed also does DNSSEC validation. ### CentOS/RHEL @@ -141,7 +141,7 @@ chattr +i /etc/resolv.conf ### FreeBSD -FreeBSD ships unbound in the base system but the one in ports is usually following upstream more closely so we install the unbound package: +FreeBSD ships unbound in the base system but the one in ports is usually following upstream more closely, so we install the unbound package: ``` pkg install unbound

1 0

[community/develop] bring DragonflyBSD to build bridges with us;
by pili＠torproject.org 18 Nov '19

18 Nov '19

commit 3c5efc632f2e3d1eab05133c83d832a95b868b51 Author: Vinicius Zavam <egypcio(a)googlemail.com> Date: Fri Oct 4 19:16:47 2019 +0000 bring DragonflyBSD to build bridges with us; - dfbsd is based on FreeBSD, and still keeps its default settings/paths; - packages names and most configurations are just the same as fbsd; - obfs4 is available! we can have more diverse bridges running :) --- .../bridge/dragonflybsd/contents.lr | 140 +++++++++++++++++++++ 1 file changed, 140 insertions(+) diff --git a/content/relay-operations/technical-setup/bridge/dragonflybsd/contents.lr b/content/relay-operations/technical-setup/bridge/dragonflybsd/contents.lr new file mode 100644 index 0000000..7300d3d --- /dev/null +++ b/content/relay-operations/technical-setup/bridge/dragonflybsd/contents.lr @@ -0,0 +1,140 @@ +_model: page +--- +color: primary +--- +title: DragonflyBSD +--- +html: two-columns-page.html +--- +key: 3 +--- +body: + +### 1. Bootstrap `pkg` + +DragonFlyBSD's daily snapshots and releases (starting with 3.4) come with `pkg` already installed. Upgrades from earlier releases, however, will not have it. + +If `pkg` is missing on the system for any reason, it can be quickly bootstrapped without having to build it from source or even having **DPorts** installed: + +``` +cd /usr +make pkg-bootstrap +rehash +pkg-static install -y pkg +rehash +``` + +##### 1.1. Recommended Steps to Setup `pkg` + +Here, it will be similar to what we have on a **FreeBSD** system, and we are going to use HTTPS to fetch our packages, and updates - so here we also need an extra package to help us out (`ca_root_nss`). + +Installing the `ca_root_nss` package: + +``` +pkg install ca_root_nss +``` + +For fresh installations, the file `/usr/local/etc/pkg/repos/df-latest.conf.sample` is copied to `/usr/local/etc/pkg/repos/df-latest`. The files ending in the ".sample" extension are ignored; pkg(8) only reads files that end in ".conf" and it will read as many as it finds. + +**DragonflyBSD** has 2 packages repositories: + + - Avalon (mirror-master.dragonflybsd.org) + - Wolfpond (pkg.wolfpond.org) + +We can simply edit the **URL** used to point out the repositories on `/usr/local/etc/pkg/repos/df-latest` and that's it! Remember to use **pkg+https://** for Avalon. + +After applying all these changes, we update the packages list again and try to check if there's already a new update to apply: + +``` +pkg update -f +pkg upgrade -y -f +``` + +### 2. Install `tor` DragonflyBSD's Package + +Here we can choose to install the latest stable version, like: + +``` +pkg install tor +``` + + ... or install an alpha release: + + +``` +pkg install tor-devel + +### 3. Configure `/usr/local/etc/tor/torrc` to run **Tor** as a Bridge + +``` +RunAsDaemon 1 +BridgeRelay 1 + +# Replace "TODO1" with a Tor port of your choice. This port must be externally +# reachable. Avoid port 9001 because it's commonly associated with Tor and +# censors may be scanning the Internet for this port. +ORPort TODO1 + +ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy + +# Replace "TODO2" with an obfs4 port of your choice. This port must be +# externally reachable and must be different from the one specified for ORPort. +# Avoid port 9001 because it's commonly associated with +# Tor and censors may be scanning the Internet for this port. +ServerTransportListenAddr obfs4 0.0.0.0:TODO2 + +# Local communication port between Tor and obfs4. Always set this to "auto". +# "Ext" means "extended", not "external". Don't try to set a specific port +# number, nor listen on 0.0.0.0. +ExtORPort auto + +# Replace "<address(a)email.com>" with your email address so we can contact you if +# there are problems with your bridge. This is optional but encouraged. +ContactInfo <address(a)email.com> + +# Pick a nickname that you like for your bridge. This is optional. +Nickname PickANickname + +Log notice file /var/log/tor/notices.log +``` + +Don't forget to change the `ORPort`, `ServerTransportListenAddr`, `ContactInfo`, and `Nickname` options. + +* Please note that both `ORPort` and the port you used as `TODO2` (for obfs4) must be reachable. If your bridge is behind a firewall or NAT, make sure to open/forward both ports. You can use [our reachability test](https://bridges.torproject.org/scan/) to see if your obfs4 port is reachable from the Internet. + +* Are you firewalling your DragonflyBSD? If so, make sure that `obfs4proxy` can talk to `tor` over the loopback interface - do not forget to whitelist the **ExtORPort**. + +### 4. Start `tor`: + +Here we set `tor` to start at boot time and use the setuid feature, in order to bind to lower ports like 443 (the daemon itself will still run as a regular non-privileged user). + +``` +echo "tor_setuid=YES" >> /etc/rc.conf +echo "tor_enable=YES" >> /etc/rc.conf +service tor start +``` + +### 5. Monitor your logs + +To confirm your bridge is running with no issues, you should see something like this in `/var/log/tor/notices.log`: + +``` +[notice] Your Tor server's identity key fingerprint is '<NICKNAME> <FINGERPRINT>' +[notice] Your Tor bridge's hashed identity key fingerprint is '<NICKNAME> <HASHED FINGERPRINT>' +[notice] Registered server transport 'obfs4' at '[::]:46396' +[notice] Tor has successfully opened a circuit. Looks like client functionality is working. +[notice] Bootstrapped 100%: Done +[notice] Now checking whether ORPort <redacted>:3818 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) +[notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. +``` + +### 6. Final Notes + +If you are having troubles setting up your bridge, have a look at [our help section](https://community.torproject.org/relay/getting-help/). If your bridge is now running, check out the [post-install notes](https://community.torproject.org/relay/setup/bridge/post-install/). + +--- +subtitle: How to deploy an obfs4 bridge on DragonflyBSD +--- +section: Bridge +--- +section_id: bridge

1 0

[community/develop] as dfBSD was sad to be added alone, we brought NetBSD to the rescue;
by pili＠torproject.org 18 Nov '19

18 Nov '19

commit 8e1d02a7490dc482ddec1be353ac54b159c8ab5f Author: Vinicius Zavam <egypcio(a)googlemail.com> Date: Fri Oct 4 22:05:44 2019 +0000 as dfBSD was sad to be added alone, we brought NetBSD to the rescue; - of course it runs netbsd ]:-) --- .../technical-setup/bridge/netbsd/contents.lr | 96 ++++++++++++++++++++++ 1 file changed, 96 insertions(+) diff --git a/content/relay-operations/technical-setup/bridge/netbsd/contents.lr b/content/relay-operations/technical-setup/bridge/netbsd/contents.lr new file mode 100644 index 0000000..8262eda --- /dev/null +++ b/content/relay-operations/technical-setup/bridge/netbsd/contents.lr @@ -0,0 +1,96 @@ +_model: page +--- +color: primary +--- +title: NetBSD +--- +html: two-columns-page.html +--- +key: 3 +--- +body: + +### 1. Setup `pkg_add` + +``` +echo "PKG_PATH=http://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/$(uname -m)/$(uname -r)/All" > /etc/pkg_install.conf +``` + +2. Install `obfs4proxy` and `tor` NetBSD's package + +``` +pkg_add obfs4proxy tor +``` + +### 2. Configure `/usr/pkg/etc/tor/torrc` to run **Tor** as a Bridge + +``` +RunAsDaemon 1 +BridgeRelay 1 + +# Replace "TODO1" with a Tor port of your choice. This port must be externally +# reachable. Avoid port 9001 because it's commonly associated with Tor and +# censors may be scanning the Internet for this port. +ORPort TODO1 + +ServerTransportPlugin obfs4 exec /usr/pkg/bin/obfs4proxy + +# Replace "TODO2" with an obfs4 port of your choice. This port must be +# externally reachable and must be different from the one specified for ORPort. +# Avoid port 9001 because it's commonly associated with +# Tor and censors may be scanning the Internet for this port. +ServerTransportListenAddr obfs4 0.0.0.0:TODO2 + +# Local communication port between Tor and obfs4. Always set this to "auto". +# "Ext" means "extended", not "external". Don't try to set a specific port +# number, nor listen on 0.0.0.0. +ExtORPort auto + +# Replace "<address(a)email.com>" with your email address so we can contact you if +# there are problems with your bridge. This is optional but encouraged. +ContactInfo <address(a)email.com> + +# Pick a nickname that you like for your bridge. This is optional. +Nickname PickANickname + +Log notice syslog +``` + +Don't forget to change the `ORPort`, `ServerTransportListenAddr`, `ContactInfo`, and `Nickname` options. + +* Please note that both `ORPort` and the port you used as `TODO2` (for obfs4) must be reachable. If your bridge is behind a firewall or NAT, make sure to open/forward both ports. You can use [our reachability test](https://bridges.torproject.org/scan/) to see if your obfs4 port is reachable from the Internet. + +* Are you firewalling your NetBSD? If so, make sure that `obfs4proxy` can talk to `tor` over the loopback interface - do not forget to whitelist the **ExtORPort**. + +### 3. Start `tor`: + +``` +ln -sf /usr/pkg/share/examples/rc.d/tor /etc/rc.d/tor +echo "tor=YES" >> /etc/rc.conf +/etc/rc.d/tor start +``` + +### 4. Monitor your logs + +To confirm your bridge is running with no issues, you should see something like this: + +``` +[notice] Your Tor server's identity key fingerprint is '<NICKNAME> <FINGERPRINT>' +[notice] Your Tor bridge's hashed identity key fingerprint is '<NICKNAME> <HASHED FINGERPRINT>' +[notice] Registered server transport 'obfs4' at '[::]:46396' +[notice] Tor has successfully opened a circuit. Looks like client functionality is working. +[notice] Bootstrapped 100%: Done +[notice] Now checking whether ORPort <redacted>:3818 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) +[notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. +``` + +### 5. Final Notes + +If you are having troubles setting up your bridge, have a look at [our help section](https://community.torproject.org/relay/getting-help/). If your bridge is now running, check out the [post-install notes](https://community.torproject.org/relay/setup/bridge/post-install/). + +--- +subtitle: How to deploy an obfs4 bridge on NetBSD +--- +section: Bridge +--- +section_id: bridge

1 0

[community/develop] IP can be many things, IP address is better here. reported by arma on irc
by pili＠torproject.org 18 Nov '19

18 Nov '19

commit a317b8ceab32626ad58305a0ea3a1bec9d98e251 Author: emma peel <emma.peel(a)riseup.net> Date: Sat Oct 12 11:56:15 2019 +0200 IP can be many things, IP address is better here. reported by arma on irc --- content/onion-services/overview/contents.lr | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/onion-services/overview/contents.lr b/content/onion-services/overview/contents.lr index f70589a..330dea4 100644 --- a/content/onion-services/overview/contents.lr +++ b/content/onion-services/overview/contents.lr @@ -24,7 +24,8 @@ Onion services offer various privacy and security benefits to their users. ### Location hiding -An onion service's IP is protected. Onion services are an overlay network on top of TCP/IP, so in some sense IP addresses are not even meaningful to onion services: they are not even used in the protocol. +An onion service's IP address is protected. +Onion services are an overlay network on top of TCP/IP, so in some sense IP addresses are not even meaningful to onion services: they are not even used in the protocol. ### End-to-end authentication

1 0

[community/develop] better strings for l10n
by pili＠torproject.org 18 Nov '19

18 Nov '19

commit 5d985dbcaabaef9f6a1f6a1273ca8ad0e06ece3e Author: emma peel <emma.peel(a)riseup.net> Date: Sat Oct 12 11:56:59 2019 +0200 better strings for l10n --- content/onion-services/overview/contents.lr | 26 ++++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/content/onion-services/overview/contents.lr b/content/onion-services/overview/contents.lr index 330dea4..1122aa1 100644 --- a/content/onion-services/overview/contents.lr +++ b/content/onion-services/overview/contents.lr @@ -16,7 +16,8 @@ html: two-columns-page.html --- body: -Onion services are services that can only be accessed over Tor. Running an onion service gives your users all the security of HTTPS with the added privacy benefits of Tor Browser. +Onion services are services that can only be accessed over Tor. +Running an onion service gives your users all the security of HTTPS with the added privacy benefits of Tor Browser. ## Why onion services? @@ -29,32 +30,41 @@ Onion services are an overlay network on top of TCP/IP, so in some sense IP addr ### End-to-end authentication -When a user visits a particular onion, they know that the content they are seeing can only come from that particular onion. No impersonation is possible, which is generally not the case. Usually, reaching a website does not mean that a man-in-the-middle did not reroute to some other location (e.g. DNS attacks). +When a user visits a particular onion, they know that the content they are seeing can only come from that particular onion. +No impersonation is possible, which is generally not the case. +Usually, reaching a website does not mean that a man-in-the-middle did not reroute to some other location (e.g. DNS attacks). ### End-to-end encryption -Onion service traffic is encrypted from the client to the onion host. This is like getting strong SSL/HTTPS for free. +Onion service traffic is encrypted from the client to the onion host. +This is like getting strong SSL/HTTPS for free. ### NAT punching -Is your network filtered and you can't open ports on your firewall? This could happen if you are in a university campus, an office, an airport, or pretty much anywhere. Onion services don't need open ports because they punch through NAT. They only establish outgoing connections. +Is your network filtered and you can't open ports on your firewall? +This could happen if you are in a university campus, an office, an airport, or pretty much anywhere. +Onion services don't need open ports because they punch through NAT. They only establish outgoing connections. ## The Onion Service Protocol: Overview -Now the question becomes **what kind of protocol is needed to achieve all these properties?** Usually, people connect to an IP address and are done, but how can you connect to something that does not have an IP address? +Now the question becomes **what kind of protocol is needed to achieve all these properties?** +Usually, people connect to an IP address and are done, but how can you connect to something that does not have an IP address? In particular, an onion service's address looks like this: `vww6ybal4bd7szmgncyruucpgfkqahzddi37ktceo3ah7ngmcopnpyyd.onion` -This looks weird and random because it's the _identity public key_ of the onion service. That's one of the reasons we can achieve the security properties above. +This looks weird and random because it's the _identity public key_ of the onion service. +That's one of the reasons we can achieve the security properties above. -The onion service protocol uses the Tor network so that the client (Alice) can introduce itself to the service (Bob), and then set up a rendezvous point with the service over the Tor network. Here is a detailed breakdown of how this happens: +The onion service protocol uses the Tor network so that the client (Alice) can introduce itself to the service (Bob), and then set up a rendezvous point with the service over the Tor network. +Here is a detailed breakdown of how this happens: ### Act 1: Where the onion service sets up its introduction points ![Onion Services: Step 1](/static/images/onion-services/overview/tor-onion-services-1.png) -As the first step in the protocol, Bob (the onion service) contacts a bunch of Tor relays and asks them to act as his _introduction points_, by establishing long-term circuits to them. These circuits are anonymized circuits, so Bob does not reveal his locations to his introduction points. +As the first step in the protocol, Bob (the onion service) contacts a bunch of Tor relays and asks them to act as his _introduction points_, by establishing long-term circuits to them. +These circuits are anonymized circuits, so Bob does not reveal his locations to his introduction points. As part of this step, Bob gives its introduction point a special "authentication key", so that if any clients come for introductions later the introduction point can use that key to match them to Bob.

1 0

[community/develop] made a few flow edits.lr
by pili＠torproject.org 18 Nov '19

18 Nov '19

commit 82f5f7c44dcf545c4b5fa75cf8ac58c4bc119acb Author: Stephanie A. Whited <steph(a)torproject.org> Date: Thu Oct 10 19:52:26 2019 +0000 made a few flow edits.lr --- content/onion-services/overview/contents.lr | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/onion-services/overview/contents.lr b/content/onion-services/overview/contents.lr index e747052..f70589a 100644 --- a/content/onion-services/overview/contents.lr +++ b/content/onion-services/overview/contents.lr @@ -24,11 +24,11 @@ Onion services offer various privacy and security benefits to their users. ### Location hiding -An onion service's IP is hidden. Onion services are an overlay network on top of TCP/IP, so in some sense IP addresses are not even meaningful to onion services: they are not even used in the protocol. +An onion service's IP is protected. Onion services are an overlay network on top of TCP/IP, so in some sense IP addresses are not even meaningful to onion services: they are not even used in the protocol. ### End-to-end authentication -When a user visits a particular onion, they know that the content they are seeing can only come from that particular onion and that no impersonation is possible. This is not the case with the normal web, where reaching a website does not mean that a man-in-the-middle did not reroute to some other location (e.g. DNS attacks). +When a user visits a particular onion, they know that the content they are seeing can only come from that particular onion. No impersonation is possible, which is generally not the case. Usually, reaching a website does not mean that a man-in-the-middle did not reroute to some other location (e.g. DNS attacks). ### End-to-end encryption @@ -36,18 +36,18 @@ Onion service traffic is encrypted from the client to the onion host. This is li ### NAT punching -Is your network filtered and you can't open ports on your firewall? This could happen if you are in a university campus, an office, an airport or pretty much anywhere. Onion services don't need open ports because they punch through NAT, since they only establish outgoing connections. +Is your network filtered and you can't open ports on your firewall? This could happen if you are in a university campus, an office, an airport, or pretty much anywhere. Onion services don't need open ports because they punch through NAT. They only establish outgoing connections. ## The Onion Service Protocol: Overview -Now the question becomes **what kind of protocol do we need to achieve all these properties?** In particular, on the normal web, we connect to an IP address and we are done, but in this case how do we connect to something that does not have an IP address? +Now the question becomes **what kind of protocol is needed to achieve all these properties?** Usually, people connect to an IP address and are done, but how can you connect to something that does not have an IP address? In particular, an onion service's address looks like this: `vww6ybal4bd7szmgncyruucpgfkqahzddi37ktceo3ah7ngmcopnpyyd.onion` -This looks weird and random because in reality it's the _identity public key_ of the onion service and that's one of the reasons we can achieve the security properties from above. +This looks weird and random because it's the _identity public key_ of the onion service. That's one of the reasons we can achieve the security properties above. -The general concept behind the onion service protocol is that we use the Tor network so that the client (Alice) can introduce itself to the service (Bob), and then sets up a rendezvous with the service. Here is a detailed breakdown of how this happens: +The onion service protocol uses the Tor network so that the client (Alice) can introduce itself to the service (Bob), and then set up a rendezvous point with the service over the Tor network. Here is a detailed breakdown of how this happens: ### Act 1: Where the onion service sets up its introduction points @@ -79,7 +79,7 @@ Now let's fast-forward to the point where an actual client wants to visit the se In this case, Alice (the client) has the onion address of Bob and she wants to visit it, so she connects to it with her Tor Browser. Now the next thing that needs to happen is that Alice goes to the _distributed hash table_ from the step above, and ask for the signed descriptor of Bob. -When Alice receives the signed descriptor she verifies the signature of the descriptor using the public key that is encoded in the onion address. +When Alice receives the signed descriptor, she verifies the signature of the descriptor using the public key that is encoded in the onion address. This provides the _end-to-end authentication_ security property, since we are now sure that this descriptor could only be produced by Bob and no one else. And inside the descriptor there are the introduction points which allow Alice to introduce herself to Bob. @@ -112,7 +112,7 @@ This provides _location hiding_ to this connection: ## Further resources -This was just a high-level overview of the Tor onion services protocol. Here are some more resources for the curious who want to learn more: +This was just a high-level overview of the Tor onion services protocol. Here are some more resources if you want to learn more: - The original Tor design paper describing the original design: https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf

1 0

[community/develop] sort layout items
by pili＠torproject.org 18 Nov '19

18 Nov '19

commit 2f8c9270e48ea0dffa2ff7876c9b30bf1782e6e6 Author: Antonela <hola(a)antonela.me> Date: Wed Oct 16 11:49:39 2019 -0300 sort layout items --- content/localization/contents.lr | 4 ++-- content/onion-services/contents.lr | 2 +- content/relay-operations/contents.lr | 2 +- content/user-research/contents.lr | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/content/localization/contents.lr b/content/localization/contents.lr index e356bc4..00b6229 100644 --- a/content/localization/contents.lr +++ b/content/localization/contents.lr @@ -12,7 +12,7 @@ subtitle: We want Tor to work for everyone in the world, which means our softwar --- cta: Help us translate --- -key: 2 +key: 4 --- html: localization.html --- @@ -22,4 +22,4 @@ body: In order for Tor to work for everyone, it needs to speak everyone's languages. Our volunteer translation team works hard to make this a reality, and we can always use more help. -Our current translation priorities are translating [Tor Browser](https://torpat.ch/locales), Tor Browser documentation, and the [Tor Project website](https://torpat.ch/tpo-locales), but there are many other documents that we could use help translating as well. +Our current translation priorities are translating [Tor Browser](https://torpat.ch/locales), Tor Browser documentation, and the [Tor Project website](https://torpat.ch/tpo-locales), but there are many other documents that we could use help translating as well. diff --git a/content/onion-services/contents.lr b/content/onion-services/contents.lr index 9e51c1c..d9af6b7 100644 --- a/content/onion-services/contents.lr +++ b/content/onion-services/contents.lr @@ -12,7 +12,7 @@ subtitle: Onion services help you and your users defeat surveillance and censors --- cta: Grow your .onion --- -key: 6 +key: 3 --- html: onion-services.html --- diff --git a/content/relay-operations/contents.lr b/content/relay-operations/contents.lr index 40f0df7..6bf4422 100644 --- a/content/relay-operations/contents.lr +++ b/content/relay-operations/contents.lr @@ -12,7 +12,7 @@ subtitle: Relays are the backbone of the Tor network. Help make Tor stronger and --- cta: Grow the Tor network --- -key: 5 +key: 6 --- html: relay-operations.html --- diff --git a/content/user-research/contents.lr b/content/user-research/contents.lr index 844d79d..5787f2c 100644 --- a/content/user-research/contents.lr +++ b/content/user-research/contents.lr @@ -12,7 +12,7 @@ subtitle: We conduct user research while also respecting user privacy. --- cta: Learn about Tor users --- -key: 4 +key: 5 --- html: user-research.html ---

1 0

[community/develop] remove user-testing section
by pili＠torproject.org 18 Nov '19

18 Nov '19

commit 8d8d0bcf22ba5b481a3eecb7e1de6654dfc98a5b Author: Antonela <hola(a)antonela.me> Date: Wed Oct 16 11:18:48 2019 -0300 remove user-testing section we are going to use user-research because it the proper name for holding all the HCD methodologies we are running --- content/user-testing/current/contents.lr | 19 ------------------- content/user-testing/signup/contents.lr | 19 ------------------- 2 files changed, 38 deletions(-) diff --git a/content/user-testing/current/contents.lr b/content/user-testing/current/contents.lr deleted file mode 100644 index d71015f..0000000 --- a/content/user-testing/current/contents.lr +++ /dev/null @@ -1,19 +0,0 @@ -section: user testing ---- -section_id: user-testing ---- -color: primary ---- -image: clipboard ---- -_template: layout.html ---- -title: Currently Testing Stuffs[FIXME] ---- -subtitle: Link to somewhere we can update more than this webpage, even banners will be tedious if we do testing all the time. We can even output some thing pulled from there and have it populated here.[FIXME] ---- -key: 1 ---- -html: user-testing.html ---- -body: diff --git a/content/user-testing/signup/contents.lr b/content/user-testing/signup/contents.lr deleted file mode 100644 index e238096..0000000 --- a/content/user-testing/signup/contents.lr +++ /dev/null @@ -1,19 +0,0 @@ -section: user testing ---- -section_id: user-testing ---- -color: primary ---- -image: eye ---- -_template: layout.html ---- -title: Sign up to be in our testing pool ---- -subtitle: Will you help us by becoming a Tor tester? Sign up for the user testing mailing list and we'll email you when there's a new test. We will never use your email for any other purposes. ---- -key: 2 ---- -html: user-testing.html ---- -body:

1 0