Planet Tor

@blog January 14, 2021 - 14:37 • 2 days ago
The State of IPv6 support on the Tor network
The State of IPv6 support on the Tor network Gaba January 14, 2021

In our last article, published in RIPE's website, we described the work that happened in 2020 related to giving IPv6 support to the Tor network.

Tor 0.4.5.1-alpha is the first release that includes all the work described in the RIPE article. Relays running 0.4.5.1-alpha are the first to report IPv6 bandwidth statistics.

Tor Versions

 

As of December 2, 2020, 54% of the relays on the network run a version of Tor that supports IPv6. Of the 6852 relays in the network, 3587 are running version 0.4.4 and 8 relays are running the latest Tor version 0.4.5. From all those, 1588 are announcing an IPv6 address and port for the OR protocol. 1587 relays are reachable on IPv6 by the directory authorities. 626 permit exiting to IPv6 targets.

 

Graph of Relays by IP Version

 The latest consensus published in November contains:

  • 6538 relays:
    • 1562 of these (36.39% TCW) have an IPv6 ORPort.
    • 1067 of these (24.86% TCW) support at least partial IPv6 reachability checks.
    •  55 of these (1.90% TCW) support full IPv6 reachability checks.
  • 2527 "usable guards" and Wgd=0.
    • 641 of these (29.73% UGCW) support IPv6 clients.
    • 446 of these (21.33% UGCW) support at least partial IPv6 reachability checks.
    • 36 of these (2.92% UGCW) support full IPv6 reachability checks.

 

Fraction of reported bytes for which IP version is known

 

The IPv6 stats that we are collecting are:

  • the number of Tor relays that support IPv6 reachability checks (full versus partial).
  • the number of Tor relays that have an IPv6 ORPort.
  • the number of connections, and consumed bandwidth, using IPv4 and IPv6. 
  • IPv6 bandwidth statistics.

 

Reminder that for relays to report IPv6 bandwidth statistics, they would have to set the option ConnDirectionStatistics to 1 and leave the ExtraInfoStatistics option enabled (it is on by default) to be able to report IPv6 bandwidth statistics. This is the relay operators’  decision, since relays are operated by volunteers. We will keep the statistics code in the codebase for when 0.4.5 is released and relays start reporting it.

...
@anarcat January 13, 2021 - 20:50 • 3 days ago
New phone: Pixel 4a

I'm sorry to announce that I gave up on the Fairphone series and switched to a Google Phone (Pixel 4a) running CalyxOS.

Problems in fairy land

My fairphone2, even if it is less than two years old, is having major problems:

  • from time to time, the screen flickers and loses "touch" until I squeeze it back together
  • the camera similarly disconnects regularly
  • even when it works, the camera is... pretty bad: low light is basically unusable, it's slow and grainy
  • the battery can barely keep up for one day
  • the cellular coverage is very poor, in Canada: I lose signal at the grocery store and in the middle of my house...

Some of those problems are known: the Fairphone 2 is old now. It was probably old even when I got it. But I can't help but feel a little sad to let it go: the entire point of that device was to make it easy to fix. But alas, because it's sold only in Europe, local stores don't carry replacement parts. To be fair, Fairphone did offer to fix the device, but with a 2 weeks turnaround, I had to get another phone anyways.

I did actually try to buy a fairphone3, from Clove. But they did some crazy validation routine. By email, they asked me to provide a photo copy of a driver's license and the credit card, arguing they need to do this to combat fraud. I found that totally unacceptable and asked them to cancel my order. And because I'm not sure the FP3 will fix the coverage issues, I decided to just give up on Fairphone until they officially ship to the Americas.

Do no evil, do not pass go, do not collect 200$

So I got a Google phone, specifically a Pixel 4a. It's a nice device, all small and shiny, but it's "plasticky" - I would have prefered metal, but it seems you need to pay much, much more to get that (in the Pixel 5).

In any case, it's certainly a better form factor than the Fairphone 2: even though the screen is bigger, the device itself is actually smaller and thinner, which feels great. The OLED screen is beautiful, awesome contrast and everything, and preliminary tests show that the camera is much better than the one on the Fairphone 2. (The be fair, again, that is another thing the FP3 improved significantly. And that is with the stock Camera app from CalyxOS/AOSP, so not as good as the Google Camera app, which does AI stuff.)

CalyxOS: success

The Pixel 4a not not supported by LineageOS: it seems every time I pick a device in that list, I manage to miss the right device by one (I bought a Samsung S9 before, which is also unsupported, even though the S8 is). But thankfully, it is supported by CalyxOS.

That install was a breeze: I was hesitant in playing again with installing a custom Android firmware on a phone after fighting with this quite a bit in the past (e.g. htc-one-s, lg-g3-d852). But it turns out their install instructions, mostly using a AOSP alliance device-flasher works absolutely great. It assumes you know about the commandline, and it does require to basically curl | sudo (because you need to download their binary and run it as root), but it Just. Works. It reminded me of how great it was to get the Fairphone with TWRP preinstalled...

Oh, and kudos to the people in #calyxos on Freenode: awesome tech support, super nice folks. An amazing improvement over the ambiance in #lineageos! :)

Migrating data

Unfortunately, migrating the data was the usual pain in the back. This should improve the next time I do this: CalyxOS ships with seedvault, a secure backup system for Android 10 (or 9?) and later which backs up everything (including settings!) with encryption. Apparently it works great, and CalyxOS is also working on a migration system to switch phones.

But, obviously, I couldn't use that on the Fairphone 2 running Android 7... So I had to, again, improvised. The first step was to install Syncthing, to have an easy way to copy data around. That's easily done through F-Droid, already bundled with CalyxOS (including the privileged extension!). Pair the devices and boom, a magic portal to copy stuff over.

The other early step I took was to copy apps over using the F-Droid "find nearby" functionality. It's a bit quirky, but really helps in copying a bunch of APKs over.

Then I setup a temporary keepassxc password vault on the Syncthing share so that I could easily copy-paste passwords into apps. I used to do this in a text file in Syncthing, but copy-pasting in the text file is much harder than in KeePassDX. (I just picked one, maybe KeePassDroid is better? I don't know.) Do keep a copy of the URL of the service to reduce typing as well.

Then the following apps required special tweaks:

  • AntennaPod has an import/export feature: export on one end, into the Syncthing share, then import on the other. then go to the queue and select all episodes and download
  • the Signal "chat backup" does copy the secret key around, so you don't get the "security number change" warning (even if it prompts you to re-register) - external devices need to be relinked though
  • AnkiDroid, DSub, Nextcloud, and Wallabag required copy-pasting passwords

I tried to sync contacts with DAVx5 but that didn't work so well: the account was setup correctly, but contacts didn't show up. There's probably just this one thing I need to do to fix this, but since I don't really need sync'd contact, it was easier to export a VCF file to Syncthing and import again.

Known problems

One problem with CalyxOS I found is that the fragile little microg tweaks didn't seem to work well enough for Signal. That was unexpected so they encouraged me to file that as a bug.

The other "issue" is that the bootloader is locked, which makes it impossible to have "root" on the device. That's rather unfortunate: I often need root to debug things on Android. In particular, it made it difficult to restore data from OSMand (see below). But I guess that most things just work out of the box now, so I don't really need it and appreciate the extra security. Locking the bootloader means full cryptographic verification of the phone, so that's a good feature to have!

OSMand still doesn't have a good import/export story. I ended up sharing the Android/data/net.osmand.plus/files directory and importing waypoints, favorites and tracks by hand. Even though maps are actually in there, it's not possible for Syncthing to write directly to the same directory on the new phone, "thanks" to the new permission system in Android which forbids this kind of inter-app messing around.

Tracks are particularly a problem: my older OSMand setup had all those folders neatly sorting those tracks by month. This makes it really annoying to track every file manually and copy it over. I have mostly given up on that for now, unfortunately. And I'll still need to reconfigure profiles and maps and everything by hand. Sigh. I guess that's a good clearinghouse for my old tracks I never use...

Update: turns out setting storage to "shared" fixed the issue, see comments below!

Conclusion

Overall, CalyxOS seems like a good Android firmware. The install is smooth and the resulting install seems solid. The above problems are mostly annoyances and I'm very happy with the experience so far, although I've only been using it for a few hours so this is very preliminary.

...
@blog January 13, 2021 - 18:57 • 3 days ago
New Release: Tor Browser 10.0.8
New Release: Tor Browser 10.0.8
sysrqb January 13, 2021

Tor Browser 10.0.8 is now available from the Tor Browser download page and also from our distribution directory.

This release updates Firefox for desktops to 78.6.1esr and Firefox for Android to 84.1.4. This version resolves instability on Apple macOS devices with the new M1 processor.

The full changelog since Desktop and Android Tor Browser 10.0.7 is:

  • All Platforms
    • Update NoScript to 11.1.7
  • Windows + OS X + Linux
    • Update Firefox to 78.6.1esr
  • Android
    • Update Firefox to 84.1.4
  • OS X
    • Bug 40262: Browser tabs crashing on the new Macbooks with the M1 chip
  • Build System
    • Android
      • Bug 40195: repo.spring.io is not usable anymore
...
@blog January 12, 2021 - 18:51 • 4 days ago
New release candidate: Tor 0.4.5.3-rc
New release candidate: Tor 0.4.5.3-rc
nickm January 12, 2021

There's a new release candidate available for download. If you build Tor from source, you can download the source code for 0.4.5.3-rc from the download page on the website. Packages should be available over the coming weeks, with a new alpha Tor Browser release in 3-4 days.

We're getting closer and closer to stable here, so I hope that people will try this one out and report any bugs they find.

Tor 0.4.5.3-rc is the first release candidate in its series. It fixes several bugs, including one that broke onion services on certain older ARM CPUs, and another that made v3 onion services less reliable.

Though we anticipate that we'll be doing a bit more clean-up between now and the stable release, we expect that our remaining changes will be fairly simple. There will be at least one more release candidate before 0.4.5.x is stable.

Changes in version 0.4.5.3-rc - 2021-01-12

  • Major bugfixes (onion service v3):
    • Stop requiring a live consensus for v3 clients and services, and allow a "reasonably live" consensus instead. This allows v3 onion services to work even if the authorities fail to generate a consensus for more than 2 hours in a row. Fixes bug 40237; bugfix on 0.3.5.1-alpha.
  • Minor features (crypto):
    • Fix undefined behavior on our Keccak library. The bug only appeared on platforms with 32-byte CPU cache lines (e.g. armv5tel) and would result in wrong digests. Fixes bug 40210; bugfix on 0.2.8.1-alpha. Thanks to Bernhard Übelacker, Arnd Bergmann and weasel for diagnosing this.

 

  • Minor features (documentation):
    • Mention the "!badexit" directive that can appear in an authority's approved-routers file, and update the description of the "!invalid" directive. Closes ticket 40188.
  • Minor bugfixes (compilation):
    • Fix a compilation warning about unreachable fallthrough annotations when building with "--enable-all-bugs-are-fatal" on some compilers. Fixes bug 40241; bugfix on 0.3.5.4-alpha.
    • Fix the "--enable-static-tor" switch to properly set the "-static" compile option onto the tor binary only. Fixes bug 40111; bugfix on 0.2.3.1-alpha.
  • Minor bugfixes (config, bridge):
    • Really fix the case where torrc has a missing ClientTransportPlugin but is configured with a Bridge line and UseBridges. Previously, we didn't look at the managed proxy list and thus would fail for the "exec" case. Fixes bug 40106; bugfix on 0.4.5.1-alpha.
  • Minor bugfixes (logging, relay):
    • Log our address as reported by the directory authorities, if none was configured or detected before. Fixes bug 40201; bugfix on 0.4.5.1-alpha.
    • When a launching bandwidth testing circuit, don't incorrectly call it a reachability test, or trigger a "CHECKING_REACHABILITY" control event. Fixes bug 40205; bugfix on 0.4.5.1-alpha.
  • Minor bugfixes (relay, statistics):
    • Report the correct connection statistics in our extrainfo documents. Previously there was a problem in the file loading function which would wrongly truncate a state file, causing the wrong information to be reported. Fixes bug 40226; bugfix on 0.4.5.1-alpha.
  • Minor bugfixes (SOCKS5):
    • Handle partial SOCKS5 messages correctly. Previously, our code would send an incorrect error message if it got a SOCKS5 request that wasn't complete. Fixes bug 40190; bugfix on 0.3.5.1-alpha.
...
@kushal January 3, 2021 - 06:08 • 14 days ago
Introducing Tumpa, to make OpenPGP simple with smartcards

Generating OpenPGP keys in an offline air-gapped system and then moving them into a smart card is always a difficult task for me. To remember the steps and command-line options of gpg2 correctly and then following them in the same order is difficult, and I had trouble enough number of times in doing so when I think about someone who is not into the command line that much, how difficult these steps are for them.

While having a chat with Saptak a few weeks ago, we came up with the idea of writing a small desktop tool to help. I started adding more features into my Johnnycanencrypt for the same. The OpenPGP operations are possible due to the amazing Sequoia project.

Introducing Tumpa

The work on the main application started during the holiday break, and today I am happy to release 0.1.0 version of Tumpa to make specific OpenPGP operations simple to use. It uses Johnnycanencrypt inside, and does not depend on the gpg.

Here is a small demo of the application running in a Tails (VM) environment. I am creating a new OpenPGP key with encryption and signing subkeys, and then putting them into a Yubikey. We are also setting the card holder's name via our tool.

Tumpa demo

We can also reset any Yubikey with just a click.

Reset Yubikey

You can download the Debian Buster package for Tails from the release page from Github. You can run from the source in Mac or Fedora too. But, if you are doing any real key generation, then you should try to do it in an air-gapped system.

You can install the package as dpkg -i ./tumpa_0.1.0+buster+nmu1_all.deb inside of Tails.

What are the current available features?

  • We can create a new OpenPGP key along with selected subkeys using Curve25519. By default, the tool will add three years for the expiration of the subkeys.
  • We can move the subkeys to a smart card. We tested only against Yubikeys as that is what we have.
  • We can set the name and public key URL on the card.
  • We can set the user pin and the admin pin of the smart card
  • We can reset a Yubikey.
  • We can export the public key for a selected key.

What is next?

A lot of work :) This is just the beginning. There are a ton of features we planned, and we will slowly add those. The UI also requires a lot of work and touch from a real UX person.

The default application will be very simple to use, and we will also have many advanced features, say changing subkey expiration dates, creating new subkeys, etc. for the advanced users.

We are also conducting user interviews (which takes around 20 minutes of time). If you have some time to spare to talk to us and provide feedback, please feel free to ping us via Twitter/mastodon/IRC.

We are available on #tumpa channel on Freenode. Come over and say hi :)

There are a lot of people I should thank for this release. Here is a quick list at random. Maybe I miss many names here, but you know that we could not do this without your help and guidance.

  • Sequoia team for all the guidance on OpenPGP.
  • Milosch Meriac for providing the guidance (and a ton of hardware).
  • Vincent Breitmoser, for keep explaining OpenKeyChain codebase to me to understand smart card operations
  • Anwesha Das for fixing the CI failures for Johnnycanencrypt, and documentation PRs.
  • Harlo and Micah, for all the amazing input for months.
  • Saptak Sengupta for being the amazing co-maintainer.
...
@blog December 23, 2020 - 14:17 • 24 days ago
In memoriam of Karsten Loesing
In memoriam of Karsten Loesing
isabela December 23, 2020

It's with deep sorrow that we share that our dear friend, colleague, and Tor core contributor Karsten Loesing passed away on the afternoon of Friday, December 18, 2020. No one is prepared for such an unimaginable loss. Our deepest sympathies go to Karsten's family at this moment, his wife and his children.

Karsten was part of the Tor community for 13 years and an amazing, smart, thoughtful, and gentle person who has touched us all. Over the course of these years we saw him not only grow as a colleague at Tor but as a father to his family. His positive, attentive, and kind presence helped us grow as people as well.

Dr. Karsten Loesing joined Tor in 2007 as a Google Summer of Code student to work on Distributed Tor Directory, and earned his PhD in Computer Science at Germany’s University of Bamberg in 2009 on a Tor-related topic, "Distributed Storage for Tor Hidden Service Descriptors".

Since 2009, Karsten was lead developer of all Java-based code in Tor metrics and became Metrics team lead in 2015. He was the original author of Tor Metrics and was one of the main authors of OnionPerf. You can watch a demonstration he did about OnionPerf at one of our recent demo days at Tor.

We all loved him and his contribution to the Tor Project will always be remembered from the depth of our hearts. We will be dedicating our next release of core tor to Karsten's memory. 

Rest in peace, Karsten.

Image credit: uni-bamberg.de press office, Kein Häuten der Zwiebel (2007).

...
@ooni December 21, 2020 - 00:00 • 27 days ago
Year in Review: OONI in 2020
In light of the global COVID-19 pandemic, 2020 has been a challenging year for everyone. Yet, several exciting things happened in the censorship measurement world. In this post, we share some OONI highlights from 2020, as well as some upcoming OONI projects for 2021! OONI Probe New OONI Probe Desktop App for Windows and macOS New OONI Probe measurement engine OONI Run usability study ...
@blog December 17, 2020 - 08:05 • 1 months ago
New Release: Tor Browser 10.5a6
New Release: Tor Browser 10.5a6
gk December 17, 2020

Tor Browser 10.5a6 is now available from the Tor Browser Alpha download page and also from our distribution directory.

Note: This is an alpha release, an experimental version for users who want to help us test new features. For everyone else, we recommend downloading the latest stable release instead.

This release updates Firefox to 78.6.0esr for desktop and Firefox for Android to 84.1.0. Additionally, we update Tor to 0.4.5.2-alpha for desktop users (Android users got that already with 10.5a5) and OpenSSL to 1.1.1i for everyone. This release includes important security updates both for desktop and Android users.

This version brings back a functioning meek bridge, and also allows users to automatically get bridges within Tor Browser again.

Note: Tor Browser 10.5 does not support CentOS 6.

The full changelog since Tor Browser 10.5a4 (desktop) and 10.5a5 (Android) is:

  • All Platforms
    • Update NoScript to 11.1.6
    • Bug 40175: Update obfs4proxy's TLS certificate public key pinning
    • Bug 40176: Update openssl to 1.1.1i
  • Windows + OS X + Linux
    • Update Firefox to 78.6.0esr
    • Update HTTPS Everywhere to 2020.11.17
    • Update Tor to 0.4.5.2-alpha
    • Bug 33803: Add a secondary nightly MAR signing key [tor-browser]
    • Bug 40138: Move our primary nightly MAR signing key to tor-browser
    • Bug 40159: Update snowflake to ece43cbf
  • Android
    • Update Fenix to 84.1.0
  • Linux
    • Bug 40226: Crash on Fedora Workstation Rawhide GNOME
  • Build System
    • All Platforms
      • Bug 40169: Update apt package cache after calling pre_pkginst, too
      • Bug 40183: Pick up Go 1.15.6
    • Windows + OS X + Linux
      • Bug 40081: Build Mozilla code with --enable-rust-simd
      • Bug 40166: Update apt cache before calling pre_pkginst in container-image config
    • Android
    • OS X
      • Bug 40147: Remove RANLIB workaround once we pick up 0.4.5.2-alpha
...
@kushal December 16, 2020 - 04:36 • 1 months ago
How to get a TLS certificate for a domain in your local network?

How to get a TLS certificate for a domain inside of my local network? This was a question for me for a long time. I thought of creating a real subdomain, getting the certificate, and copying over the files locally, and then enforcing local domain names via the DNS or /etc/hosts. But, during the TLS training from Scott Helme, I learned about getting certificates via DNS challenge using acme.sh.

I use DreamHost nameservers for most of m domains. I got an API_KEY from them for only DNS manipulation.

Next, I just had to execute one single command along with the API_KEY to fetch fresh and hot certificate from Let's Encrypt.

The following command fetches for fire.das.community subdomain.

DH_API_KEY=MYAPIKEY acme.sh --issue --dns dns_dreamhost -d fire.das.community

There is a wiki page listing how to use acme.sh tool for various DNS providers.

...
@blog December 15, 2020 - 17:39 • 1 months ago
New Release: Tor Browser 10.0.7
New Release: Tor Browser 10.0.7
sysrqb December 15, 2020

Update 2020-12-22 20:00 UTC: Tor Browser 10.0.7 is approved now on Google Play and it is rolling out.

Tor Browser 10.0.7 is now available from the Tor Browser download page and also from our distribution directory.

This release updates Firefox for desktops to 78.6.0esr and Firefox for Android to 84.1.0. This release includes important security updates to Firefox for Desktop, and similar important security updates to Firefox for Android.

Note: This update is not available on Google Play at this time because the update was rejected during the review process. We are appealing the rejection and working with Google so this update is available as soon as possible.

The full changelog since Desktop and Android Tor Browser 10.0.6 is:

  • All Platforms
    • Update HTTPS Everywhere to 2020.11.17
    • Bug 40166: Disable security.certerrors.mitm.auto_enable_enterprise_roots
    • Bug 40176: Update openssl to 1.1.1i
  • Windows + OS X + Linux
    • Update Firefox to 78.6.0esr
  • Android
    • Update Firefox to 84.1.0
    • Update NoScript to 11.1.6
  • Linux
    • Bug 40226: Crash on Fedora Workstation Rawhide GNOME
  • Build System
    • All Platforms
    • Android
      • Bug 40128: Allow updating Fenix allowed_addons.json
      • Bug 40140: Create own Gradle project
      • Bug 40155: Update toolchain for Fenix 84
      • Bug 40156: Update Fenix and dependencies to 84.0.0-beta2
      • Bug 40163: Avoid checking hash of .pom files
      • Bug 40171: Include all uniffi-rs artifacts into application-services
      • Bug 40184: Update Fenix and deps to 84.1.0
...
@kushal December 13, 2020 - 12:08 • 1 months ago
Open Source Project Criticality Score 2020 for python projects

I just now found about Open Source Project Criticality Score under the Open Source Security Foundation (OpnSSF) from Daniel Stenberg's blog post.

He wrote about the critical C projects (all calculations are done only for Github based projects), so I decided to look at the list of the Python projects.

It is a score between 0 (least critical) and 1 (most critical), and the algorithm and details are explained in the repository.

The list of top 10 Python projects in their resultset

It is interesting to see that the CPython is at number 8 in the list and the top two projects are configuration management systems.

You can see all the different language details here.

...
@blog December 10, 2020 - 18:52 • 1 months ago
Tor in 2021
Tor in 2021
isabela December 10, 2020

This year has been difficult for all of us. As individuals, we’ve had to adapt to the new normal of COVID-19, and as an organization, the Tor Project also had to adapt to our “new normal” after we made the difficult decision to let go of one third of our organization. Although challenging, we have managed to reorganize in order to meet the goals we originally set for 2020, and now, it’s time to look forward to 2021.

Continuing User-First Development

Since I joined the Tor Project back in 2015 as a Project Manager, my primary goal has been to incorporate a user-centric development method, and create a way for us to test our tools with users and use their feedback to guide our work. This was not an easy task; in 2015, we didn’t even have a UX team, and since we don’t collect invasive user data like much of the tech industry, we needed to build a way to directly engage with our users face-to-face in order to do this work. For the past three years, every Tor Browser release has featured usability improvements guided by this program. In 2021, we will continue to work on improving our tools based on feedback from users, and we hope to be focusing on Tor Launcher by incorporating it to Tor Browser and improving the usability for censored users when bypassing censorship and connecting to Tor.

Improving Network Performance and Network Health

An important part of improving the usability of Tor’s tools is improving the performance of the Tor network. We started the foundation for work to improve network performance in 2020 and we are looking forward to continuing it in 2021. Some of the experiments we conducted this year showed an amazing improvement in network speed, and we hope that this work will address one of the major complaints we hear, that “Tor is slow.”

Network health is a related area of work that requires our attention. In 2019, we founded a Network Health team, but because of the layoffs in 2020, we had to direct our staff capacity to other parts of the organization. We already have items on our roadmap to ensure the continuation of this work for 2021, and we hope to add a dedicated person to support our relay operators community. Relay operators are foundational to the existence of Tor, and ensuring a good relationship with them is fundamental for the health of the network and community. We will also continue our work to implement the Walking Onions, which removes the need for clients to download the full network consensus when connecting to Tor, making it possible to add more relays without degrading performance or security on the network.

Expanding Mobile Support

Another area we have invested in the past is to bring the ‘mobile first’ mentality to our development, we invested in making a Tor Browser for Android and have done some improvements in our network to help mobile apps developers to incorporate support for Tor to their apps. In 2021 we hope to create the foundation work for some major changes that will contribute to our ‘mobile first’ approach. We are investigating different needs users have while using Tor on Desktop in comparison with using Tor on Mobile. We are investing in making sure that our anti-censorship tools work well in a mobile environment.

Developing ARTI

If you watched the recent State of the Onion, you probably saw Nick Mathewson talk about ARTI, which stands for “A Rust Tor Implementation,” in which we are using the Rust programming language as it is much safer and productive to work with. Our goal is to create a smaller, safer Tor client that will be easier to embed in applications, especially mobile apps. ARTI will ensure more collaboration and be easier to maintain, ensuring Tor’s longevity. We hope that by the end of 2021, we have something we can recommend for secure use and start testing. Eventually ARTI could also become something that relays can use. ARTI could eventually have a more robust API for developers to help them integrate Tor to their applications. We also hope to continue adding support for IPv6 and other types of support, such as UDP traffic, to Tor.

Investigating Tokens

In 2020, we spent time exploring the possibility of implementing tokens to solve a variety of issues, including DDoS attacks against onion services and requesting bridges. In 2021, we hope to continue this exploration and we hope to design a token system for Tor as well as the initial implementation of this system in some basic use cases. This is a lot of work, and we still need to ensure funds to support this process, but we see how tokens can be useful for many use cases in the future, so we will do our best to ensure we can pursue this in 2021 and move it into a more concrete area of work.

Working to Unblock Tor

In 2020, we ran a campaign called #MoreOnionsPorFavor to increase visibility to onion service technology and its adoption. We received great engagement from a wide range of different sites and services, including blogs, news agencies, law firms, human rights NGOs, email and VPN providers, cryptocurrency sites,and other products that integrated .onion addresses and Onion-Location as a privacy and security feature for their users. In 2021, we want to continue this type of outreach work and initiate a campaign to call on services that are blocking connections from the Tor network to unblock Tor and stop punishing privacy and anonymity. We plan to invest in educational materials that address some of the reasons these services might have to be blocking Tor, offer alternative solutions, and we hope that this campaign will improve our users' experience as they browse the web.

Welcome 2021!

Like I said at the beginning of this blog post, 2020 has been a challenging year for everyone, and it was not different for Tor. 

As the year ends, we can look back and see how we made the best out of all these challenges. The reorganization of the Tor Project opened new channels of communication within the organization that weren’t in place before. We started a weekly All Hands meeting to sync as an organization, and we have introduced Demo Days that are open for our community to share the projects we’re all working on. I would say that our culture has evolved within this process. Sometimes when an organization is faced with the challenges like we faced this year, organizational culture can suffer, and I am proud to say that was not the case for us at Tor. 

I am very thankful for the team we have and for the community that is always around us and supporting us. Our plans for 2021 demonstrate how ambitious we are in making a better Tor that’s accessible to everyone and how dedicated we are to fulfilling our mission. And in times like these--where an internet connection has become crucial for workers, educators, health care, human rights defenders, journalists to do their work--we understand how important it is that everybody knows that Tor is here for them to use and that it will continue to improve. 

If you want to support the projects I’ve outlined above, and all the work Tor does to bring privacy online to millions of people, please make a donation. Your contributions make an impact on whether or not we can complete these plans, and every donation, no matter the size, makes a difference.

tor donate button

Thank you for always supporting us, I wish everyone at Tor and who are part of our community a great 2021. 

...
@kushal December 10, 2020 - 09:52 • 1 months ago
PrivChat with Tor: 2020-12-11 Tor advancing human rights

Tomorrow, on 11th December, 2020 at 18:00UTC, Tor will host the third edition of the PrivChat event, to discuss with some real life Tor users and talk about how Tor helps them to defend human rights. You can watch it live on Youtube.

image of snowden

The event will be hosted by Edward Snowden, President, Freedom of the Press Foundation. We have Alison Macrina (Founder, Library Freedom Project), Berhan Taye ( Africa Policy Manager and Global Internet Shutdowns Lead, Access Now) and Ramy Raoof (Security Labs Technologist, Amnesty International) as participants in the discussion.

...
@blog December 9, 2020 - 19:52 • 1 months ago
New Release: Tor Browser 10.0.6
New Release: Tor Browser 10.0.6
sysrqb December 09, 2020

Tor Browser 10.0.6 is now available from the Tor Browser download page and also from our distribution directory.

This version brings back a functioning meek bridge, and also allows users to automatically get bridges within Tor Browser again.

The full Desktop and Android changelogs since Tor Browser 10.0.5 is:

  • All Platforms
    • Bug 40175: Update obfs4proxy's TLS certificate public key pinning
...
@blog December 7, 2020 - 23:07 • 1 months ago
New Release: Tor Browser 10.5a5 (Android Only)
New Release: Tor Browser 10.5a5 (Android Only)
sysrqb December 07, 2020

Tor Browser 10.5a5 is now available from the Tor Browser Alpha download page and also from our distribution directory.

Note: This is an alpha release, an experimental version for users who want to help us test new features. For everyone else, we recommend downloading the latest stable release for Android instead.

This release updates Fenix to 84.0.0-beta.2. Additionally, we update Tor to 0.4.5.2-alpha and HTTPS Everywhere to 2020.11.17.

The full changelog since Tor Browser 10.5a4 is:

  • Android
    • Update Fenix to 84.0.0-beta.2
    • Update HTTPS Everywhere to 2020.11.17
    • Update Tor to 0.4.5.2-alpha
    • Translations update
    • Bug 40159: Update snowflake to ece43cbf
    • Bug 40236: Rebase tor-browser patches to 84.0b1
    • Bug 40258: Rebase tor-browser patches to 84.0b7
    • Bug 40119: Rebase Fenix patches to Fenix 84 beta 2
    • Bug 40027: Rebase android-components patches for Fenix 84 beta 2 builds
  • Build System
    • Android
      • Bug 40081: Build Mozilla code with --enable-rust-simd
      • Bug 40128: Allow updating Fenix allowed_addons.json
      • Bug 40140: Create own Gradle project
      • Bug 40147: Remove RANLIB workaround once we pick up 0.4.5.2-alpha
      • Bug 40155: Update toolchain for Fenix 84
      • Bug 40156: Update Fenix and dependencies to 84.0.0-beta2
      • Bug 40161: Pick up Go 1.15.5
      • Bug 40163: Bug 40163: Avoid checking hash of .pom files
      • Bug 40166: Update apt cache before calling pre_pkginst in container-image config
      • Bug 40171: Include all uniffi-rs artifacts into application-services
...
@blog December 7, 2020 - 22:39 • 1 months ago
Anti-censorship team report: November 2020
Anti-censorship team report: November 2020
Philipp Winter December 07, 2020

Tor's anti-censorship team writes monthly reports to keep the world updated on its progress. This blog post summarizes the anti-censorship work we got done in November 2020. Let us know if you have any questions or feedback!

Snowflake

Rdsys

Salmon

Bridgestrap

Other

...
@kushal December 7, 2020 - 11:07 • 1 months ago
Story of debugging exit 0

For more than a month, my primary task at SecureDrop land is to make the project ready for a distribution update. The current system runs on Ubuntu Xenial, and the goal is to upgrade to Ubuntu Focal. The deadline is around February 2021, and we will also disable Onion service v2 in the same release.

Tracking issue

There is a tracking issue related to all the changes for Focal. After the initial Python language-related updates, I had to fix the Debian packages for the same. Then comes the Ansible roles for the whole system, setting up the rebase + full integration tests for the system in CI. A lot of new issues were found when we managed to get Focal based staging instances in the CI.

OSSEC test failure

This particular test is failing on Focal staging. It checks for the port 1514 listening on UDP on the monitor server via OSSEC. The first thing we noticed that the output of the command is different in Xenial and on Focal. While looking at the details, we also noticed that the OSSEC service is failing on Focal. Now, this starts via a sysv script in the /etc/init.d/ directory. My initial try was to follow the solution mentioned here. But, the maild service was still failing most of the time. Later, I decided to move to a more straightforward forking based service file. Works well for the OSSEC monitoring service. So, I decided to have the same systemd service file for the agent in the app server.

But, the installation step via Ansible failed before any configuration. When we install the .deb packages, our configuration provider package tries to restart the service via the post-installation script. And that fails with a complaint that /var/ossec/etc/client.keys is not found. If I try to start the service manually, I get the same error with an exit code 1.

At this moment, I was trying to identify how was it working before, we are using the same codebase + the sysv on Xenial, but package installation works. The systemd generates the following service file:

# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/ossec
Description=LSB: Start daemon at boot time
After=remote-fs.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/ossec start
ExecStop=/etc/init.d/ossec stop

After digging for hours, I noticed exit 0 at the end of the old sysv script. This file was last modified by late James Dolan around seven years ago, and we never had to touch the same.

Now I am planning to have 1 in the SuccessExitStaus= line of the service file for the agent. This will keep the behavior the same as the old sysv file. 

[Unit]
Description=OSSEC service

[Service]
Type=forking
ExecStart=/var/ossec/bin/ossec-control start
ExecStop=/var/ossec/bin/ossec-control stop
RemainAfterExit=True
SuccessExitStatus=1

[Install]
WantedBy=multi-user.target
...
@blog November 27, 2020 - 23:29 • 2 months ago
New Release: Tor Browser 10.0.5
New Release: Tor Browser 10.0.5
sysrqb November 27, 2020

Updated on 27 November 2020: Android Tor Browser 10.0.5 is now available. (Originally published on 17 November)

Tor Browser 10.0.5 is now available from the Tor Browser download page and also from our distribution directory.

This release updates Firefox on desktops to 78.5.0esr, Fenix on Android to 83.1.0 and updates Tor to 0.4.4.6. This release includes important security updates to Desktop Firefox, and important security updates to Android Firefox.

Note: Android Tor Browser 10.0.5 is delayed until next week. In the future, new Tor Browser versions for Android and Desktop should be published at the same time.

The full changelog since Tor Browser 10.0.4 (Desktop) is:

  • Windows + OS X + Linux
    • Update Firefox to 78.5.0esr
    • Update Tor to 0.4.4.6
    • Bug 40212: Add new default obfs4 bridge

The full changelog since Tor Browser 10.0.4 (Android) is:

  • Android
    • Update Fenix to 83.1.0
    • Update Tor to 0.4.4.6
    • Bug 40212: Add new default obfs4 bridge
  • Build System
    • Android
      • Bug 40126: Update toolchains for Fenix 83
      • Bug 40126: Bump Node to 10.22.1 for mozilla83
      • Bug 40127: Update GeckoView to 83, android-components to 63.0.1, and Fenix to 83.0.0b2
      • Bug 40160: Update Fenix to 83.1.0, and android-components to 63.0.9
      • Bug 40211: Lower required build-tools version to 29.0.2
...
@blog November 23, 2020 - 19:12 • 2 months ago
New alpha release: Tor 0.4.5.2-alpha
New alpha release: Tor 0.4.5.2-alpha
nickm November 23, 2020

There's a new alpha release available for download. If you build Tor from source, you can download the source code for 0.4.5.2-alpha from the download page on the website. Packages should be available over the coming weeks, with a new alpha Tor Browser release by mid-December.

Remember, this is an alpha release: you should only run this if you'd like to find and report more bugs than usual.

Tor 0.4.5.2-alpha is the second alpha release in the 0.4.5.x series. It fixes several bugs present in earlier releases, including one that made it impractical to run relays on Windows. It also adds a few small safety features to improve Tor's behavior in the presence of strange compile-time options, misbehaving proxies, and future versions of OpenSSL.

Changes in version 0.4.5.2-alpha - 2020-11-23

  • Major bugfixes (relay, windows):
    • Fix a bug in our implementation of condition variables on Windows. Previously, a relay on Windows would use 100% CPU after running for some time. Because of this change, Tor now require Windows Vista or later to build and run. Fixes bug 30187; bugfix on 0.2.6.3-alpha. (This bug became more serious in 0.3.1.1-alpha with the introduction of consensus diffs.) Patch by Daniel Pinto.
  • Minor features (compilation):
    • Disable deprecation warnings when building with OpenSSL 3.0.0 or later. There are a number of APIs newly deprecated in OpenSSL 3.0.0 that Tor still requires. (A later version of Tor will try to stop depending on these APIs.) Closes ticket 40165.

 

  • Minor features (protocol, proxy support, defense in depth):
    • Respond more deliberately to misbehaving proxies that leave leftover data on their connections, so as to make Tor even less likely to allow the proxies to pass their data off as having come from a relay. Closes ticket 40017.
  • Minor features (safety):
    • Log a warning at startup if Tor is built with compile-time options that are likely to make it less stable or reliable. Closes ticket 18888.
  • Minor bugfixes (circuit, handshake):
    • In the v3 handshaking code, use connection_or_change_state() to change the state. Previously, we changed the state directly, but this did not pass the state change to the pubsub or channel objects, potentially leading to bugs. Fixes bug 32880; bugfix on 0.2.3.6-alpha. Patch by Neel Chauhan.
  • Minor bugfixes (compilation):
    • Use the correct 'ranlib' program when building libtor.a. Previously we used the default ranlib, which broke some kinds of cross-compilation. Fixes bug 40172; bugfix on 0.4.5.1-alpha.
    • Remove a duplicate typedef in metrics_store.c. Fixes bug 40177; bugfix on 0.4.5.1-alpha.
    • When USDT tracing is enabled, and STAP_PROBEV() is missing, don't attempt to build. Linux supports that macro but not the BSDs. Fixes bug 40174; bugfix on 0.4.5.1-alpha.
  • Minor bugfixes (configuration):
    • Exit Tor on a misconfiguration when the Bridge line is configured to use a transport but no corresponding ClientTransportPlugin can be found. Prior to this fix, Tor would attempt to connect to the bridge directly without using the transport, making it easier for adversaries to notice the bridge. Fixes bug 25528; bugfix on 0.2.6.1-alpha.
    • Fix an issue where an ORPort was compared with other kinds of ports, when it should have been only checked against other ORPorts. This bug would lead to "DirPort auto" getting ignored. Fixes bug 40195; bugfix on 0.4.5.1-alpha.
    • Fix a bug where a second non-ORPort with a variant family (ex: SocksPort [::1]:9050) would be ignored due to a configuration parsing error. Fixes bug 40183; bugfix on 0.4.5.1-alpha.
  • Minor bugfixes (crash, relay, signing key):
    • Avoid assertion failures when we run Tor from the command line with `--key-expiration sign`, but an ORPort is not set. Fixes bug 40015; bugfix on 0.3.2.1-alpha. Patch by Neel Chauhan.
  • Minor bugfixes (logging):
    • Remove trailing whitespace from control event log messages. Fixes bug 32178; bugfix on 0.1.1.1-alpha. Based on a patch by Amadeusz Pawlik.
    • Turn warning-level log message about SENDME failure into a debug- level message. (This event can happen naturally, and is no reason for concern). Fixes bug 40142; bugfix on 0.4.1.1-alpha.
  • Minor bugfixes (relay, address discovery):
    • Don't trigger an IP change when no new valid IP can be found. Fixes bug 40071; bugfix on 0.4.5.1-alpha.
    • When attempting to discover our IP, use a simple test circuit, rather than a descriptor fetch: the same address information is present in NETINFO cells, and is better authenticated there. Fixes bug 40071; bugfix on 0.4.5.1-alpha.
  • Minor bugfixes (testing):
    • Fix the `config/parse_tcp_proxy_line` test so that it works correctly on systems where the DNS provider hijacks invalid queries. Fixes part of bug 40179; bugfix on 0.4.3.1-alpha.
    • Fix unit tests that used newly generated list of routers so that they check them with respect to the date when they were generated, not with respect to the current time. Fixes bug 40187; bugfix on 0.4.5.1-alpha.
    • Fix our Python reference-implementation for the v3 onion service handshake so that it works correctly with the version of hashlib provided by Python 3.9. Fixes part of bug 40179; bugfix on 0.3.1.6-rc.
    • Fix the `tortls/openssl/log_one_error` test to work with OpenSSL 3.0.0. Fixes bug 40170; bugfix on 0.2.8.1-alpha.
  • Removed features (controller):
    • Remove the "GETINFO network-status" controller command. It has been deprecated since 0.3.1.1-alpha. Closes ticket 22473.

    • Tor 0.4.5.2-alpha is the second alpha release in the 0.4.5.x series. It fixes several bugs present in earlier releases, including one that made it impractical to run relays on Windows. It also adds a few small safety features to improve Tor's behavior in the presence of strange compile-time options, misbehaving proxies, and future versions of OpenSSL.

    Changes in version 0.4.5.2-alpha - 2020-11-23

    • Major bugfixes (relay, windows):
      • Fix a bug in our implementation of condition variables on Windows. Previously, a relay on Windows would use 100% CPU after running for some time. Because of this change, Tor now require Windows Vista or later to build and run. Fixes bug 30187; bugfix on 0.2.6.3-alpha. (This bug became more serious in 0.3.1.1-alpha with the introduction of consensus diffs.) Patch by Daniel Pinto.
    • Minor features (compilation):
      • Disable deprecation warnings when building with OpenSSL 3.0.0 or later. There are a number of APIs newly deprecated in OpenSSL 3.0.0 that Tor still requires. (A later version of Tor will try to stop depending on these APIs.) Closes ticket 40165.

     

    • Minor features (protocol, proxy support, defense in depth):
      • Respond more deliberately to misbehaving proxies that leave leftover data on their connections, so as to make Tor even less likely to allow the proxies to pass their data off as having come from a relay. Closes ticket 40017.
    • Minor features (safety):
      • Log a warning at startup if Tor is built with compile-time options that are likely to make it less stable or reliable. Closes ticket 18888.
    • Minor bugfixes (circuit, handshake):
      • In the v3 handshaking code, use connection_or_change_state() to change the state. Previously, we changed the state directly, but this did not pass the state change to the pubsub or channel objects, potentially leading to bugs. Fixes bug 32880; bugfix on 0.2.3.6-alpha. Patch by Neel Chauhan.
    • Minor bugfixes (compilation):
      • Use the correct 'ranlib' program when building libtor.a. Previously we used the default ranlib, which broke some kinds of cross-compilation. Fixes bug 40172; bugfix on 0.4.5.1-alpha.
      • Remove a duplicate typedef in metrics_store.c. Fixes bug 40177; bugfix on 0.4.5.1-alpha.
      • When USDT tracing is enabled, and STAP_PROBEV() is missing, don't attempt to build. Linux supports that macro but not the BSDs. Fixes bug 40174; bugfix on 0.4.5.1-alpha.
    • Minor bugfixes (configuration):
      • Exit Tor on a misconfiguration when the Bridge line is configured to use a transport but no corresponding ClientTransportPlugin can be found. Prior to this fix, Tor would attempt to connect to the bridge directly without using the transport, making it easier for adversaries to notice the bridge. Fixes bug 25528; bugfix on 0.2.6.1-alpha.
      • Fix an issue where an ORPort was compared with other kinds of ports, when it should have been only checked against other ORPorts. This bug would lead to "DirPort auto" getting ignored. Fixes bug 40195; bugfix on 0.4.5.1-alpha.
      • Fix a bug where a second non-ORPort with a variant family (ex: SocksPort [::1]:9050) would be ignored due to a configuration parsing error. Fixes bug 40183; bugfix on 0.4.5.1-alpha.
    • Minor bugfixes (crash, relay, signing key):
      • Avoid assertion failures when we run Tor from the command line with `--key-expiration sign`, but an ORPort is not set. Fixes bug 40015; bugfix on 0.3.2.1-alpha. Patch by Neel Chauhan.
    • Minor bugfixes (logging):
      • Remove trailing whitespace from control event log messages. Fixes bug 32178; bugfix on 0.1.1.1-alpha. Based on a patch by Amadeusz Pawlik.
      • Turn warning-level log message about SENDME failure into a debug- level message. (This event can happen naturally, and is no reason for concern). Fixes bug 40142; bugfix on 0.4.1.1-alpha.
    • Minor bugfixes (relay, address discovery):
      • Don't trigger an IP change when no new valid IP can be found. Fixes bug 40071; bugfix on 0.4.5.1-alpha.
      • When attempting to discover our IP, use a simple test circuit, rather than a descriptor fetch: the same address information is present in NETINFO cells, and is better authenticated there. Fixes bug 40071; bugfix on 0.4.5.1-alpha.
    • Minor bugfixes (testing):
      • Fix the `config/parse_tcp_proxy_line` test so that it works correctly on systems where the DNS provider hijacks invalid queries. Fixes part of bug 40179; bugfix on 0.4.3.1-alpha.
      • Fix unit tests that used newly generated list of routers so that they check them with respect to the date when they were generated, not with respect to the current time. Fixes bug 40187; bugfix on 0.4.5.1-alpha.
      • Fix our Python reference-implementation for the v3 onion service handshake so that it works correctly with the version of hashlib provided by Python 3.9. Fixes part of bug 40179; bugfix on 0.3.1.6-rc.
      • Fix the `tortls/openssl/log_one_error` test to work with OpenSSL 3.0.0. Fixes bug 40170; bugfix on 0.2.8.1-alpha.
    • Removed features (controller):
      • Remove the "GETINFO network-status" controller command. It has been deprecated since 0.3.1.1-alpha. Closes ticket 22473.
...
@blog November 20, 2020 - 12:46 • 2 months ago
From Trac into Gitlab for Tor
From Trac into Gitlab for Tor
Gaba November 20, 2020
Tor has been using Trac until June 2020, when we moved to our self-hosted instance of Gitlab administered by the Tor sysadmin team. We reached some limitations with Trac as well as were concern on some of the plugins we depended on not being mantained. The challenges on doing this migration sooner were and are related to the capacity that we have to adapt a new ticketing system to our needs.
 
We're hoping Gitlab will be a good fit because:
  • Gitlab will allow us to collect our different engineering tools into a single application: Git repository handling, Wiki, Issue tracking, Code reviews, and project management tooling.
  • Gitlab is well-maintained, while Trac plugins are not well maintained and Trac itself hasn't seen a release for over a year (since 2019).
  • Gitlab will allow us to build a more modern approach to handling Continuous Integration for our different projects. This is going to happen after the ticket and wiki migration.
 
We spent several months fixing and testing problems on data migration, from formatting issues to where the information of trac goes to live to in Gitlab. We tested the Gitlab instance with a few projects until we jumped into migrating all data from Trac. You can read about the use cases for a bug tracker at Tor in this ticket. 
 
To accomplish the migration, the Gitlab migration group wrote a number of tools to make the migration happen. These tools were split into two parts: one part for fetching all the state from Trac and a number of tool from turning the Trac state into Gitlab issues and wiki content in various ways. The migration group worked with the engineering teams in the organisation on issues such as splitting up Trac "flat ticket namespace" into the different groups and projects that we wanted to have on Gitlab. This allowed the individual teams at Tor to decide the organisation they wanted to have on Gitlab and allow them to build a mapping that fits better with the project model of Gitlab, where each project have an issue tracker, a wiki, and a repository attached.
 
We specified a specific date for the migration to happen where all of Tor's engineering teams were asked to find different means of doing their work than using Trac while Trac was put in read-only mode. During this period the migration group worked together on the actual migration, verifying that all data was properly migrated to a point where things looked satisfying, and then finally we announced that Gitlab was what we would move to next. We did the transition period with start on Friday afternoon over the weekend to ensure that only a minimum amount of disruption would be caused by this.
 
The period after the migration did involve a bit of support handling from the different teams, but we ar amazed at how quickly everybody picked up the new work flows and we believe that Gitlab have made it easier for engineers to make choices around their respective projects now without needing help from the Gitlab admin team.
 
We are not migrating away from Gitolite and Jenkins just yet. This means those services are still fully operational and their equivalent features in GitLab are not supported (namely Git hosting and CI). Those services might eventually be migrated to GitLab.
 
The issues and wiki of the "Tor" project are migrated. There are no other projects in Trac.
Trac issues that remain are really legacy issues, others issues have been "moved" to the respective projects. All the tickets that were not moved to their respective projects have been closed in the first week of July 2020. Next year we will permanently shut Trac down and keep it archived in the Wayback machine.
 
To request a new account you have to fill the form in https://gitlab.onionize.space/ where we get the request and a few of us attend to them. Through the Outreachy Internship we are mentoring an intern that will help improve this application.
 
To be able to have all issues in one same board we created a main group "tpo" where all our projects live. The structure for the rest of the projects is:
 

Organization: host our main wiki, which links to documentation for all projects at TPO. It also hold issues that may not be related to any particular project but are organizational on TPO.

TPA: host any project related to the infrastructure administered by TPO

  • Gitlab : Any issue or documentation related to running the Gitlab instance.
  • Team: Any issue related to administering TP infrastructure

Core: host projects that are related to mantaining little-t tor

  • arti, tor specifications, shadow, trunnel, tor socks, fallback scripts, directory authorities, chutney, tor
  • Team: Any issue related to processes for the core team and the wiki.

Anti-Censorship: host projects that work on circumventing censorship with Tor

  • gettor, pluggable transports, rdsys, bridgedb, censorship analysis, bridgestrap, emma, state of censorship
  • Team: Any issue related to processes of the team and the wiki.

Network Health: it has all the projects related to monitoring the Tor network

  • doctor, exitmap, torflow, sbws, helper scripts
  • Team: Issues related to network health in general but not to specific projects.

Applications: everything at Tor that is a user facing product

  • tor browser projects, tor launcher, https everywhere
  • Team: issues and wiki related to processes of the team that work on user facing products

Metrics: everything related to collecting, analyzing and visualizing data from the Tor network

  • collector, metrics website, onionperf, weather ,utilities, analysis, exit scanner, exonerator
  • Team: issues and wiki related to the team

Community: is for all the projects that help people that help Tor. 

  • l10n, support, outreach, training
  • Team: anything about processes for the community

Web: all projects and code related to the websites that the Tor project mantains

  • support portal, community, torproject.org main website, donations, styleguide

UX: all projects related to user experience in all the software we develop at the Tor project

  • design, research, media
  • Team: anything about the people working on UX at Tor
 
You can read more about Tor's Gitlab instance in the documentation.
 
Edit: For any question not related to Gitlab or Trac please send a mail to frontdesk at torproject dot org. Thanks!
...
@blog November 19, 2020 - 21:40 • 2 months ago
Transparency, Openness, and Our 2018 and 2019 Finances
Transparency, Openness, and Our 2018 and 2019 Finances
arma November 19, 2020

After completing standard audits for 2017-2018 and for 2019, our federal tax filings and audits are available. We publish all of our related tax documents for transparency.

Specifically, there are four new documents:

  • The 2018 Form 990 (our tax document), covering January through June of 2018.
  • The 2018 Financial statements and audit results, covering January 2017 through June 2018.
  • The 2019 Form 990, covering July 2018 to June 2019.
  • The 2019 Financial statements and audit results, covering July 2018 to June 2019.

The reason these documents are no longer tied to calendar years is because in 2017 we changed our fiscal year to be "July through June", since having our fiscal year end right in the middle of fundraising season (Dec 31) makes it harder to plan budgets.

Remember that transparency for a privacy project is not a contradiction: privacy is about choice, and we choose to publish all of these aspects of our work in order to build a stronger community. Transparency is about where the money comes from, but it's also about what we do with it: we show you all of our projects, in source code, and in periodic project and team reports, and in collaborations with researchers who help assess and improve Tor. Transparency also means being clear about our values, promises, and priorities as laid out in our social contract.

The board has also continued to publish minutes for seven board meetings in 2018, six meetings in 2019, and three so far in 2020.

The last few years have been a bit bumpy financially, because we grew to be able to cover more of the Tor ecosystem (which was great), but our expenses grew faster than our income (not so great). That approach is sustainable for a while by spending reserves, but once you're out of reserves the remaining option is to solve it by reducing expenses. You can see part of that arc in the 2017-2019 documents here, and the other half of the arc (the more cheerful half) will be included in the 2020-2021 documents.

One contributing factor to the bumpiness is that we didn't expand our grant writing in 2017 as much as (in retrospect) we should have. This challenge makes it even clearer why being dependent on a small set of funding sources impacts our robustness — a few big grant proposals getting rejected rather than accepted was the difference for 2018. Further amplifying the challenge is that for many funders, the time between proposal and decision can be a full year or more, which makes planning ahead both harder and essential.

Some observations to help you read through the 2018 and 2019 financial documents:

  • Tor's revenue for the half-year of 2018 was $1.76 million, and for FY2019 was a bit under $4.9 million. So things have continued to grow, and the hard part is to make sure that revenue and expenses grow together.
  • 2019 marks the first year since 2005 (before Tor was incorporated as a non-profit) where more than half our support came from sources other than the US government. In terms of percentages, 2015-2016-2017 were 85%, 76%, and 51% US government sources respectively. For the half-year 2018 it went back up to 70%, but for 2019 the fraction of our funding that came from US government sources dropped all the way to 42%. We should expect this percentage to keep going up and down in the future, but one of our priorities remains to continue working to reduce our reliance on US government sources.
  • We also had the highest contributions ever from individuals—$577k—due to the hard work of our fundraising team. Thank you to the broader Tor community for the support! This support is especially valuable because unrestricted donations let us work on the topics and projects that are most important at the time.
  • Remember the big picture though: Tor's budget remains modest considering the number of people involved and the impact we have. And it is dwarfed by the budgets that our adversaries are spending to make the world a more dangerous and less free place.
  • Check out the comment sections on the previous posts for previous years' versions of the usual "omg government funding" and "omg transparency" discussions. You might find this comment more useful than the rest.
  • When people ask me about Tor funding, I explain that we have four categories of funders: (A) Research funding from groups like the National Science Foundation to do fundamental research on privacy and censorship, including studying how to improve Tor's performance and safety, and inventing new censorship circumvention techniques. (B) R&D funding from groups like OTF and DARPA to actually build safer tools. Different funders might have different audiences in mind when they help us make Tor Browser safer and easier to use, but they want the same things out of Tor Browser: in all cases we make all of our work public, and also remember that anonymity loves company. (C) Deployment and teaching funding from organizations like the US State Dept and Sweden's foreign ministry to do in-country security trainings, user-oriented documentation, and otherwise help activists around the world learn how to be safer on the internet. (D) Core organizational support, primarily from individual donations (that's you!), to cover the day-to-day operations of the non-profit, and most importantly to let us spend time on critical tasks that we can't convince a funder to care enough about.
  • More generally, I should take a brief moment to explain how funding proposals work, for those who worry that governments come to us wanting to pay us to do something bad. The way it works is that we try to find groups with funding for the general area that we want to work on, and then we go to them with a specific plan for what we'd like to do and how much it will cost, and if we're lucky they say ok. There is never any point where somebody comes to us and says "I'll pay you $X to do Y."
  • In half-of-2018 and 2019 we counted $216k and $738k in "donated services," that is, volunteers helping with translations, website hosting, and contributed patches. Thank you!
  • The 990 forms have a "Schedule B Contributors" list, which is standard practice for the accountants to anonymize (in case some contributors want to stay anonymous). Here's how they match up to funder names: contributors #1-5 in 2018 correspond to DRL, NSF part one, NSF part two, a grant via NYU for the Library Freedom Project, and Rose Foundation. And contributors #1-5 in 2019 correspond to Mozilla, DRL, NSF, Sida, and the Handshake Foundation.

In closing, remember that there are many different ways to get involved with Tor, and we need your help. For example, you can donate, volunteer, and run a Tor relay. Now is a great time to make a contribution and join our year end campaign and help us resist the surveillance pandemic. Give today, and Friends of Tor will match your donation. Double your impact by making a gift now, and remember, Use a Mask, Use Tor. 

...
@blog November 18, 2020 - 10:23 • 2 months ago
New Release: Tor Browser 10.5a4
New Release: Tor Browser 10.5a4
gk November 18, 2020

Tor Browser 10.5a4 is now available from the Tor Browser Alpha download page and also from our distribution directory.

Note: This is an alpha release, an experimental version for users who want to help us test new features. For everyone else, we recommend downloading the latest stable release for desktop or Android instead.

This release updates Firefox to 78.5.0esr for desktop and Fenix to 83.0 for Android. Additionally, we update Tor to 0.4.5.1-alpha. This release includes important security updates both for desktop and Android users.

Note: Tor Browser 10.5 does not support CentOS 6.

The full changelog since Tor Browser 10.5a3 is:

  • All Platforms
    • Update Tor to 0.4.5.1-alpha
    • Bug 40212: Add new default bridge "PraxedisGuerrero"
  • Windows + OS X + Linux
    • Update Firefox to 78.5.0esr
  • Android
    • Update Fenix to 83.1.0
    • Bug 27002: (Mozilla 1673237) Always allow SVGs on about: pages
    • Bug 40137: Built-in https-everywhere storage is not migrated to idb
    • Bug 40152: Top Crash: android.database.sqlite.SQLiteConstraintException
    • Bug 40205: Replace occurrence of EmptyCString with 0-length _ns literal
    • Bug 40206: Disable the /etc/hosts parser
    • Translations update
  • Build System
    • OS X
    • Android
      • Bug 40211: Lower required build-tools version to 29.0.2
      • Bug 40126: Bump Node to 10.22.1 for mozilla83
      • Bug 40127: Update components for switch to mozilla83-based Fenix
...
@blog November 13, 2020 - 15:01 • 2 months ago
New Release: Tor Browser 10.5a3
New Release: Tor Browser 10.5a3
sysrqb November 13, 2020

Tor Browser 10.5a3 for Desktop platforms is now available from the Tor Browser Alpha download page and also from our distribution directory.

Note: This is an alpha release, an experimental version for users who want to help us test new features. For everyone else, we recommend downloading the latest stable release instead.

Tor Browser 10.5a3 updates NoScript to 11.1.5 and libevent to 2.1.12. This release includes important security updates to Firefox.

Note: Tor Browser 10.5 does not support CentOS 6.

The full changelog since Tor Browser 10.5a2 is:

  • All Platforms
    • Update NoScript to 11.1.5
    • Bug 40022: EOY November Update - Matching
    • Bug 40064: Bump libevent to 2.1.12
    • Translations update
  • Windows + OS X + Linux
    • Bug 27002: (Mozilla 1673237) Always allow SVGs on about: pages
    • Bug 40021: Keep page shown after Tor Browser update purple
    • Bug 40137: Migrate https-everywhere storage to idb
    • Bug 40219: Backport fix for Mozilla's bug 1675905
  • Android
    • Pick up fix for Mozilla's bug 1675905 (with GeckoView 82.0.3)
    • Bug 40106: EOY November Update - Matching
  • Build System
    • All Platforms
    • Windows + OS X + Linux
      • Bug 40133: Bump Rust version for ESR 78 to 1.43.0
...
@blog November 12, 2020 - 15:39 • 2 months ago
New Releases: Tor 0.3.5.12, 0.4.3.7, and 0.4.4.6
New Releases: Tor 0.3.5.12, 0.4.3.7, and 0.4.4.6
nickm November 12, 2020

We have a new stable release today. If you build Tor from source, you can download the source code for 0.4.4.6 on the download page. Packages should be available within the next several weeks, with a new Tor Browser likely next week.

We've also released 0.3.5.12 (changelog) and 0.4.3.7 (changelog) today. You can find the source for them at https://dist.torproject.org/, along with older releases.

Tor 0.4.4.6 is the second stable release in the 0.4.4.x series. It backports fixes from later releases, including a fix for TROVE-2020- 005, a security issue that could be used, under certain cases, by an adversary to observe traffic patterns on a limited number of circuits intended for a different relay.

Changes in version 0.4.4.6 - 2020-11-12

  • Major bugfixes (security, backport from 0.4.5.1-alpha):
    • When completing a channel, relays now check more thoroughly to make sure that it matches any pending circuits before attaching those circuits. Previously, address correctness and Ed25519 identities were not checked in this case, but only when extending circuits on an existing channel. Fixes bug 40080; bugfix on 0.2.7.2-alpha. Resolves TROVE-2020-005.
  • Minor features (directory authorities, backport from 0.4.5.1-alpha):
    • Authorities now list a different set of protocols as required and recommended. These lists have been chosen so that only truly recommended and/or required protocols are included, and so that clients using 0.2.9 or later will continue to work (even though they are not supported), whereas only relays running 0.3.5 or later will meet the requirements. Closes ticket 40162.
    • Make it possible to specify multiple ConsensusParams torrc lines. Now directory authority operators can for example put the main ConsensusParams config in one torrc file and then add to it from a different torrc file. Closes ticket 40164.

 

  • Minor features (subprotocol versions, backport from 0.4.5.1-alpha):
    • Tor no longer allows subprotocol versions larger than 63. Previously version numbers up to UINT32_MAX were allowed, which significantly complicated our code. Implements proposal 318; closes ticket 40133.
  • Minor features (tests, v2 onion services, backport from 0.4.5.1-alpha):
    • Fix a rendezvous cache unit test that was triggering an underflow on the global rend cache allocation. Fixes bug 40125; bugfix on 0.2.8.1-alpha.
    • Fix another rendezvous cache unit test that was triggering an underflow on the global rend cache allocation. Fixes bug 40126; bugfix on 0.2.8.1-alpha.
  • Minor bugfixes (compilation, backport from 0.4.5.1-alpha):
    • Fix compiler warnings that would occur when building with "--enable-all-bugs-are-fatal" and "--disable-module-relay" at the same time. Fixes bug 40129; bugfix on 0.4.4.1-alpha.
    • Resolve a compilation warning that could occur in test_connection.c. Fixes bug 40113; bugfix on 0.2.9.3-alpha.
  • Minor bugfixes (logging, backport from 0.4.5.1-alpha):
    • Remove a debug logging statement that uselessly spammed the logs. Fixes bug 40135; bugfix on 0.3.5.0-alpha.
  • Minor bugfixes (relay configuration, crash, backport from 0.4.5.1-alpha):
    • Avoid a fatal assert() when failing to create a listener connection for an address that was in use. Fixes bug 40073; bugfix on 0.3.5.1-alpha.
  • Minor bugfixes (v2 onion services, backport from 0.4.5.1-alpha):
    • For HSFETCH commands on v2 onion services addresses, check the length of bytes decoded, not the base32 length. Fixes bug 34400; bugfix on 0.4.1.1-alpha. Patch by Neel Chauhan.
...