Updates from the Tor Project

Updates from the Tor Project Updates from the Tor Project’s Official Blog.

  • New Release: Tor Browser 11.0a7
    by sysrqb on September 25, 2021 at 1:55 pm

    New Release: Tor Browser 11.0a7 sysrqb September 25, 2021 Tor Browser 11.0a7 is now available from the Tor Browser 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 Windows/macOS/Linux or Android release instead. This version updates Firefox to version 78.14.0esr on Windows, macOS, and Linux, and this version updates Firefox’s GeckoView component to 92.0 on Android. This version includes important security updates to Firefox on Windows, macOS, and Linux, and Android. Warning: Tor Browser Alpha does not support version 2 onion services. Tor Browser (Stable) will stop supporting version 2 onion services very soon. Please see the deprecation F.A.Q. entry regarding Tor version 0.4.6. Migrate your services and update your bookmarks to version 3 onion services as soon as possible. The full changelog since Tor Browser 11.0a6: All Platforms Update Openssl to 1.1.1l Windows + OS X + Linux Update Firefox to 78.14.0esr Bug 40597: Implement TorSettings module Android Bug 40611: Rebase geckoview patches onto 92.0 OS X Bug 40358: Make OpenSSL 1.1.1l buildable for macOS

  • V3 onion services usage
    by Gus on September 21, 2021 at 11:29 am

    V3 onion services usage Gus September 21, 2021 Guest post by Tobias Höller With the deprecation of V2 onion services right around the corner, it is a good time to talk about V3 onion services. This post will discuss the most important privacy improvements provided by V3 onion services as well as their limitations. Aware of those limitations, our research group at the Institute of Network and Security at JKU Linz conducted an experiment that extracts information about how V3 onion services are being used from the Tor network. Privacy improvements in V3 The most obvious difference between V2 and V3 onion services is the different address format. V3 onion addresses have 56 characters instead of 16 (because they contain a full ed25519 public key, not just the hash of a public key), meaning that migrating from V2 to V3 requires all users to learn/remember/save a new onion address address. The main reason behind this change is tied to a key component of all onion services, the hidden service directory. Its purpose is to provide the information needed to connect to a specified onion address (just like the DNS system does for regular domain names). To protect the privacy of onion service users, the hidden service directory is a distributed hash table formed by all Tor relays which possess the HSDir flag. For V2 onion services, the data published in the hidden service directory is uploaded in plain text, meaning that the Tor relays with the HSDir flag can learn a lot of information about a small fraction of running V2 onion services (most importantly the onion address) every day. Note that collecting and probing V2 onion addresses via HSDir relays is considered malicious behavior and sanctioned by Tor’s bad-relays team. V3 uses encryption and key derivation to address this issue. Since the V3 address is itself a public key, all the data uploaded to the hidden service directory can be encrypted. Clients can always decrypt that data with the key embedded in the .onion address. However, clients still need to ask the directory for information about a specific onion address, which would again allow mass collection of onion addresses. With V3 onion services, this is prevented by using key derivation to derive a daily-rotated identifier (“blinded public key”). So instead of asking the hidden service directory for facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion, the Tor client automatically calculates the current identifier from the onion address and the current date (e.g. 2021-08-19), and asks for that blinded public key (here: ek4gJEtlHmwwadLvMNG7tYx/lJuJN1zQl6pMVkGmAcM). Collectable information Thanks to these improvements, V3 onion services leak much less sensitive information. However, these changes do not completely stop the hidden service directory from revealing interesting metadata. First, it is possible to estimate the number of running onion services by counting the number of uploaded blinded public keys because every onion address translates to exactly one blinded public key per day. This means that it is possible to count onion addresses by counting blinded public keys which is already used by the Tor Project to collect statistical information about the number V3 onion services since Tor version 0.4.6.1-alpha (just like they have been doing for V2 for a long time now). This is expected to increase as soon as a sufficient number of Tor relays start to report data allowing for reliable V3 statistics (hint: remember to keep your Tor relays up-to-date). By collecting detailed logs of uploads and downloads of blinded public keys, HSDir relays can track many more statistical metrics about V3 onion services and their usage. For example, one could track how many uploaded blinded public keys are never requested or how many client requests for blinded public keys could not be answered. To get a feeling for how interesting this data might be, we designed an experiment where we deployed 50 relays with the HSDir flag and modified them to log every upload and download of blinded public keys. We tried our best to set this up in a privacy-friendly way that does not endanger individual Tor users by reducing the precision of timestamps and randomly sorting our database to destroy order. In addition, we actively asked for feedback on our experiment design from the Tor research safety board (which we integrated in our setup) and even created a plan on what to do if law enforcement would show up with a warrant (which thankfully did not happen so far). Some results After walking you through all the theory it’s time to share some of the data we collected since deploying our relays on March 1st, 2021. During this period we registered more than 131 million uploads for ~4.5 million different blinded public keys and more than 225 million download attempts for ~3.4 million different blinded public keys. A nice example for utilizing information about downloads is to track how many blinded public keys uploaded to our servers were actually downloaded. In the same fashion we can also check how many download attempts we received that could not be answered because they requested keys that had never been uploaded to us. Our Venn diagram shows that a vast majority of uploaded blinded public keys are never downloaded, indicating that these onion services are barely used. In case you are wondering how an onion service can be used if we do not see any downloads for it, that is due to the redundant nature of the hidden service directory. There is always more than just one relay to download from (by default 6 HSDir relays are responsible for a blinded public key). So even if we see zero downloads, other relays might have seen some, making it impossible to distinguish unused and barely used onion services in our data. We also see that the majority of download requests asked for blinded public keys that had never been uploaded to us. Again, this does not mean that clients see this failure (because Tor tries all 6 responsible HSDir nodes before giving up) but it indicates that lots of requests for .onion addresses ask for services that are no longer operational. A particularly interesting finding was that a few blinded public keys receive a huge amount of download requests without ever being uploaded to our relays. In our data we identified 14 blinded public keys with more than 2 million download attempts despite not having any upload attempt. This indicates that a few onion services (or even only one?) are frequently requested although they are not operational. We believe this pattern to be the product of either DDOS attacks against a specific onion service or members of a defunct botnet trying to reach their C&C server. Let’s wrap this post up with an estimate on the number of V3 onion services that have already been deployed in the Tor network: Note that our experiment collects data from 50 Tor relays which accounts for only about 1% of the hidden service directory. Therefore, our results give a first good estimate on the total number of V3 onion services but are certainly not as reliable as you would expect for statistics at Tor metrics. Nevertheless, it is certain that the number of deployed V3 onion services has been on the rise throughout 2021. So if you still operate only a V2 onion service, now would be a great time to get on board and upgrade to V3. Finally, if you are interested in more details on our experiment setup and results, read the full paper: On the state of V3 onion services (by T. Hoeller, M. Roland, R. Mayrhofer). And if you happen to operate a V3 onion service that suffered a DDOS attack in 2021 or know a botnet that uses a V3 onion service and are willing to share that information with me, please get in touch with me at tobias[dot]hoeller[at]ins[dot]jku[dot]at.

  • New Alpha Release: Tor 0.4.7.1-alpha
    by ahf on September 17, 2021 at 6:57 pm

    New Alpha Release: Tor 0.4.7.1-alpha ahf September 17, 2021 There’s a new alpha release available for download. If you build Tor from source, you can download the source code for 0.4.7.1-alpha from the download page on the website. Packages should be available over the coming weeks, with a new alpha Tor Browser release likely some time next week. Remember, this is an alpha release: you should only run this if you’d like to find and report more bugs than usual. This version is the first alpha release of the 0.4.7.x series. One major feature is Vanguards Lite, from proposal 333, to help mitigate guard discovery attacks against onion services. It also includes numerous bugfixes. Changes in version 0.4.7.1-alpha – 2021-09-17 Major features (Proposal 332, onion services, guard selection algorithm): Clients and onion services now choose four long-lived “layer 2” guard relays for use as the middle hop in all onion circuits. These relays are kept in place for a randomized duration averaging 1 week. This mitigates guard discovery attacks against clients and short-lived onion services such as OnionShare. Long-lived onion services that need high security should still use the Vanguards addon (https://github.com/mikeperry-tor/vanguards). Closes ticket 40363; implements proposal 333. Minor features (bridge testing support): Let external bridge reachability testing tools discard cached bridge descriptors when setting new bridges, so they can be sure to get a clean reachability test. Implements ticket 40209.   Minor features (fuzzing): When building with –enable-libfuzzer, use a set of compiler flags that works with more recent versions of the library. Previously we were using a set of flags from 2017. Closes ticket 40407. Minor features (testing configuration): When TestingTorNetwork is enabled, skip the permissions check on hidden service directories. Closes ticket 40338. On a testing network, relays can now use the TestingMinTimeToReportBandwidth option to change the smallest amount of time over which they’re willing to report their observed maximum bandwidth. Previously, this was fixed at 1 day. For safety, values under 2 hours are only supported on testing networks. Part of a fix for ticket 40337. Relays on testing networks no longer rate-limit how frequently they are willing to report new bandwidth measurements. Part of a fix for ticket 40337. Relays on testing networks now report their observed bandwidths immediately from startup. Previously, they waited until they had been running for a full day. Closes ticket 40337. Minor bugfixes (circuit padding): Don’t send STOP circuit padding cells when the other side has already shut down the corresponding padding machine. Fixes bug 40435; bugfix on 0.4.0.1-alpha. Minor bugfixes (compatibility): Fix compatibility with the most recent Libevent versions, which no longer have an evdns_set_random_bytes() function. Because this function has been a no-op since Libevent 2.0.4-alpha, it is safe for us to just stop calling it. Fixes bug 40371; bugfix on 0.2.1.7-alpha. Minor bugfixes (control, sandbox): Allows the control command SAVECONF to succeed when the seccomp sandbox is enabled. Makes SAVECONF keep only one backup file, to simplify implementation. Fixes bug 40317; bugfix on 0.2.5.4-alpha. Patch by Daniel Pinto. Minor bugfixes (heartbeat): Adjust the heartbeat log message about distinct clients to consider the HeartbeatPeriod rather than a flat 6-hour delay. Fixes bug 40330; bugfix on 0.2.6.3-alpha. Minor bugfixes (logging, relay): Add spaces between the “and” when logging the “Your server has not managed to confirm reachability for its” on dual-stack relays. Fixes bug 40453; bugfix on 0.4.5.1-alpha. Patch by Neel Chauhan. Minor bugfixes (onion service): Do not flag an HSDir as non-running in case the descriptor upload or fetch fails. An onion service closes pending directory connections before uploading a new descriptor which leads to wrongly flagging many relays and thus affecting circuit path selection. Fixes bug 40434; bugfix on 0.2.0.13-alpha. Minor bugfixes (statistics): Fix a fencepost issue when we check stability_last_downrated where we called rep_hist_downrate_old_runs() twice. Fixes bug 40394; bugfix on 0.2.0.5-alpha. Patch by Neel Chauhan. Minor bugfixes (tests): Fix a bug that prevented some tests from running with the correct names. Fixes bug 40365; bugfix on 0.4.3.1-alpha. Documentation: Add links to original tor design paper and anonbib to docs/HACKING/README.1st.md. Closes ticket 33742. Patch from Emily Bones. Describe the “fingerprint-ed25519” file in the tor.1 man page. Fixes bug 40467; bugfix on 0.4.3.1-alpha. Patch by Neel Chauhan.

  • New Release: Tor Browser 10.5.6 (Windows, macOS, Linux)
    by sysrqb on September 8, 2021 at 6:43 pm

    New Release: Tor Browser 10.5.6 (Windows, macOS, Linux) sysrqb September 08, 2021 Tor Browser 10.5.6 is now available from the Tor Browser download page and also from our distribution directory. This version updates Firefox to 78.14.0esr. This version includes important security updates to Firefox. Warning: Tor Browser will stop supporting version 2 onion services very soon. Please see the previously published deprecation timeline. Migrate your services and update your bookmarks to version 3 onion services as soon as possible. The full changelog since Tor Browser 10.5.5: Windows + OS X + Linux Update Firefox to 78.14.0esr Update Openssl to 1.1.1l Build System OS X Bug 40358: Make OpenSSL 1.1.1l buildable for macOS

  • New Release: Tails 4.22
    by Tails on September 7, 2021 at 12:21 pm

    New Release: Tails 4.22 Tails September 07, 2021 In Tails 4.22, we focused on solving the most important issues in the Tor Connection assistant to make it more robust and easier to use. Changes and updates Included software and hardware support Update Tor Browser to 10.5.6. Update Thunderbird to 78.13. Update the AMD graphics firmware to 20210818. This should improve the support for some AMD graphics cards. Tor Connection Change the custom bridge interface to only allow entering 1 bridge. (#18550) People had troubles knowing how to enter their custom bridges when the widget was a textarea and only the first bridge is used anyway. Allow saving 1 custom bridge in the Persistent Storage. (#5461) Allow fixing the clock manually when connecting to Tor using bridges fails. (#15548) This helps people East from London connect to Tor using obfs4 bridges and makes connecting to Tor more robust in general. Reduce the timeout that determines whether we can connect to Tor at all from 30 seconds to 10 seconds. Increase the timeout to start Tor entirely from 120 seconds to 600 seconds. (#18501).Tor Connection now fails quicker when it’s impossible to connect to Tor, while being more robust on slow Internet connections. Allow trying again to connect to Tor from the error screen. (#18539) Unsafe Browser Stop restarting Tor when exiting the Unsafe Browser. (#18562) Only mention the Persistent Storage in the Unsafe Browser warning when there is already a Persistent Storage. (#18551) Others Make sure that automatic upgrades are downloaded from a working mirror. (#15755) Add Russian to the offline documentation included in Tails. Fixed problems Tor Connection Fix connecting to Tor using the default bridges. (#18462) Fix connecting to Tor when the Wi-Fi settings are saved in the Persistent Storage. (#18532) Stop trying to connect to Tor in the background when Tor Connection reaches the error screen. (#18740) For more details, read our changelog. Known issues None specific to this release. See the list of long-standing issues. Get Tails 4.22 To upgrade your Tails USB stick and keep your persistent storage Automatic upgrades are broken from Tails 4.14 and earlier. Follow our instructions to do an automatic upgrade from Tails 4.15, Tails 4.16, Tails 4.17, or Tails 4.18. Automatic upgrades are available from Tails 4.19 or later to 4.22. You can reduce the size of the download of future automatic upgrades by doing a manual upgrade to the latest version. If you cannot do an automatic upgrade or if Tails fails to start after an automatic upgrade, please try to do a manual upgrade. To install Tails on a new USB stick Follow our installation instructions: Install from Windows Install from macOS Install from Linux The Persistent Storage on the USB stick will be lost if you install instead of upgrading. To download only If you don’t need installation or upgrade instructions, you can download Tails 4.22 directly: For USB sticks (USB image) For DVDs and virtual machines (ISO image) What’s coming up? Tails 4.23 is scheduled for October 5. Have a look at our roadmap to see where we are heading to. Support and feedback For support and feedback, visit the Support section on the Tails website.

  • New Release: Tor Browser 11.0a6 (Android Only)
    by sysrqb on September 2, 2021 at 12:00 pm

    New Release: Tor Browser 11.0a6 (Android Only) sysrqb September 02, 2021 Tor Browser 11.0a6 is now available from the Tor Browser 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 version updates Fenix’s Geckoview component to 92.0b9. Warning: Tor Browser Alpha does not support version 2 onion services. Tor Browser (Stable) will stop supporting version 2 onion services very soon. Please see the deprecation F.A.Q. entry regarding Tor version 0.4.6. Migrate your services and update your bookmarks to version 3 onion services as soon as possible. The full changelog since Tor Browser 11.0a5: Android Bug 40611: Rebase geckoview patches onto 92.0b9

  • New Release: Tor Browser 11.0a5
    by sysrqb on August 24, 2021 at 3:36 pm

    New Release: Tor Browser 11.0a5 sysrqb August 24, 2021 Tor Browser 11.0a5 is now available from the Tor Browser 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 version updates Tor to 0.4.6.7 that includes a fix for a security issue. On Android, this version updates Firefox to 91.2.0. Warning: Tor Browser Alpha does not support version 2 onion services. Tor Browser (Stable) will stop supporting version 2 onion services very soon. Please see the deprecation F.A.Q. entry regarding Tor version 0.4.6. Migrate your services and update your bookmarks to version 3 onion services as soon as possible. The full changelog since Tor Browser 11.0a4: All Platforms Update Tor to 0.4.6.7 Linux Bug 40582: Tor Browser 10.5.2 tabs always crash on Fedora Xfce Rawhide Android Update Fenix to 91.2.0

  • New Release: Tor Browser 10.5.5
    by sysrqb on August 20, 2021 at 1:30 pm

    New Release: Tor Browser 10.5.5 sysrqb August 20, 2021 Tor Browser 10.5.5 is now available from the Tor Browser download page and also from our distribution directory. This version updates Tor to 0.4.5.10 that includes a fix for a security issue. On Android, this version updates Firefox to 91.2.0 and includes important security updates. Warning: Tor Browser will stop supporting version 2 onion services very soon. Please see the previously published deprecation timeline. Migrate your services and update your bookmarks to version 3 onion services as soon as possible. The full changelog since Tor Browser 10.5.4: All Platforms Update Tor to 0.4.5.10 Linux Bug 40582: Tor Browser 10.5.2 tabs always crash on Fedora Xfce Rawhide Android Update Fenix to 91.2.0 Update NoScript to 11.2.11 Bug 40063: Move custom search providers Bug 40176: TBA: sometimes I only see the banner and can’t tap on the address bar Bug 40181: Remove V2 Deprecation banner on about:tor for Android Bug 40184: Rebase fenix patches to fenix v91.0.0-beta.5 Bug 40185: Use NimbusDisabled Bug 40186: Hide Credit Cards in Settings Build System Android Update Go to 1.15.15 Bug 40331: Update components for mozilla91

  • Join Tor Project’s Documentation Hackathon: August 30 – September 3
    by Gus on August 19, 2021 at 10:27 pm

    Join Tor Project’s Documentation Hackathon: August 30 – September 3 Gus August 19, 2021 Between August 30 and September 3, the Tor Project will host the third edition of our user documentation hackathon, the DocsHackathon. If you’ve never volunteered with us before, this is a great opportunity for you to become involved in the community, get closer to our work, and make meaningful contributions. The DocsHackathon is a totally remote and online event. Documentation is extremely valuable to the health of open source software projects, but it is often overlooked. We are a small team at the Tor Project, and as a nonprofit organization with a big mission, we rely on volunteer contributions around the world to keep up with an ever-changing internet freedom landscape with the appropriate tools to navigate it. Keeping Tor’s documentation up-to-date, organized, and accessible is a way to potentially help millions of people access a private, secure, and uncensored internet by using our tools. If you helped out in the previous editions (2020, 2019), we hope you can join us again or help spread the word. Once the #DocsHackathon is completed, we’ll reward the top three contributors with official Tor swag. So if you’re a copywriter, front-end dev, tester, or content reviewer, we’d appreciate your help improving our documentation, updating our support and community portal, and ensuring their relevancy. Don’t feel like any of these apply to you but still want to help out? Chat with us on IRC (#tor-www – irc.oftc.net) or the Community team mailing list to join us and find out where you could add value. ## How to join the event To participate in the DocsHackathon: 1. Register to get access to the event agenda: https://survey.torproject.org/index.php/212451 2. Join the Community team mailing list. 3. Take a look at all of the tickets marked with the “DocsHackathon” keyword on GitLab. 4. If you have a documentation issue that is not currently reflected on GitLab, create it, tag it DocsHackathon, and let one of us know on IRC channel #tor-www. If you prefer, you can submit new issues using Anon-Ticket. 5. Choose a ticket and start working on it! You can submit Pull Requests on our GitHub mirror or from your own git instance. 6. This isn’t a requirement, but: if you want to talk about the hackathon on social media, we’re using the tag #DocsHackathon. A contribution will be counted when your PR or merge request is merged to the master branch of the relevant repository. The awards to contributors will be announced after all the merges are done. We are a small nonprofit with a big mission, and we sincerely appreciate your help getting our documentation up to speed. We look forward to working with you soon.

  • New Release: Tor Browser 11.0a4
    by sysrqb on August 17, 2021 at 3:13 am

    New Release: Tor Browser 11.0a4 sysrqb August 16, 2021 Tor Browser 11.0a4 is now available from the Tor Browser 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 Windows/macOS/Linux or Android release instead. This version updates Firefox to version 78.13.0esr on Windows, macOS, and Linux, and Firefox to version 91.1.0 on Android. This version includes important security updates to Firefox on Windows, macOS, and Linux, and Android. Warning: Tor Browser Alpha does not support version 2 onion services. Tor Browser (Stable) will stop supporting version 2 onion services very soon. Please see the deprecation F.A.Q. entry regarding Tor version 0.4.6. Migrate your services and update your bookmarks to version 3 onion services as soon as possible. The full changelog since Tor Browser 11.0a3: All Platforms Windows + OS X + Linux Update Firefox to 78.13.0esr Bug 40041: Remove V2 Deprecation banner on about:tor for desktop Bug 40534: Cannot open URLs on command line with Tor Browser 10.5 Bug 40547: UX: starting in offline mode can result in difficulty to connect later Bug 40561: Refactor about:torconnect implementation Bug 40567: RFPHelper is not init until after about:torconnect bootstraps Android Update Fenix to 91.1.0 Bug 40186: Hide Credit Cards in Settings Build System All Platforms Update Go to 1.16.7

  • New Stable Releases: Tor 0.3.5.16, 0.4.5.10 and 0.4.6.7
    by dgoulet on August 16, 2021 at 7:34 pm

    New Stable Releases: Tor 0.3.5.16, 0.4.5.10 and 0.4.6.7 dgoulet August 16, 2021 Greetings! We have a new stable release today. If you build Tor from source, you can download the source code for the latest stable release on the download page. Packages should be available within the next several weeks, with a new Tor Browser later this week. The ChangeLog for 0.4.6.7 follows below. For the changelogs for other releases, see the announcement email. These releases backport stability fixes from later Tor releases, and a security issue classified as HIGH per our policy. Tor 0.4.6.7 fixes several bugs from earlier versions of Tor, including one that could lead to a denial-of-service attack. Everyone running an earlier version, whether as a client, a relay, or an onion service, should upgrade to Tor 0.3.5.16, 0.4.5.10, or 0.4.6.7. Changes in version 0.4.6.7 – 2021-08-16 Major bugfixes (cryptography, security): Resolve an assertion failure caused by a behavior mismatch between our batch-signature verification code and our single-signature verification code. This assertion failure could be triggered remotely, leading to a denial of service attack. We fix this issue by disabling batch verification. Fixes bug 40078; bugfix on 0.2.6.1-alpha. This issue is also tracked as TROVE-2021-007 and CVE-2021-38385. Found by Henry de Valence. Minor feature (fallbackdir): Regenerate fallback directories list. Close ticket 40447.  Minor features (geoip data): Update the geoip files to match the IPFire Location Database, as retrieved on 2021/08/12. Minor bugfix (crypto): Disable the unused batch verification feature of ed25519-donna. Fixes bug 40078; bugfix on 0.2.6.1-alpha. Found by Henry de Valence. Minor bugfixes (onion service): Send back the extended SOCKS error 0xF6 (Onion Service Invalid Address) for a v2 onion address. Fixes bug 40421; bugfix on 0.4.6.2-alpha. Minor bugfixes (relay): Reduce the compression level for data streaming from HIGH to LOW in order to reduce CPU load on the directory relays. Fixes bug 40301; bugfix on 0.3.5.1-alpha. Minor bugfixes (timekeeping): Calculate the time of day correctly on systems where the time_t type includes leap seconds. (This is not the case on most operating systems, but on those where it occurs, our tor_timegm function did not correctly invert the system’s gmtime function, which could result in assertion failures when calculating voting schedules.) Fixes bug 40383; bugfix on 0.2.0.3-alpha.

  • New Release: Tor Browser 10.5.4 (Windows, macOS, Linux)
    by sysrqb on August 10, 2021 at 4:33 pm

    New Release: Tor Browser 10.5.4 (Windows, macOS, Linux) sysrqb August 10, 2021 Tor Browser 10.5.4 is now available from the Tor Browser download page and also from our distribution directory. This version updates Firefox to 78.13.0esr. This version includes important security updates to Firefox. Warning: Tor Browser will stop supporting version 2 onion services very soon. Please see the previously published deprecation timeline. Migrate your services and update your bookmarks to version 3 onion services as soon as possible. The full changelog since Tor Browser 10.5.2: Windows + OS X + Linux Update Firefox to 78.13.0esr Update NoScript to 11.2.11 Bug 40041: Remove V2 Deprecation banner on about:tor for desktop Bug 40506: Saved Logins not available in 10.5 Bug 40524: Update DuckDuckGo onion site URL in search preferences and onboarding Build System Windows + OS X + Linux Update Go to 1.15.14

  • New Release: Tor Browser 11.0a3 (Android Only)
    by sysrqb on August 6, 2021 at 3:04 am

    New Release: Tor Browser 11.0a3 (Android Only) sysrqb August 05, 2021 Tor Browser 11.0a3 is now available from the Tor Browser 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 version updates Fenix to 91.0.0-beta.5. Warning: Tor Browser Alpha does not support version 2 onion services. Tor Browser (Stable) will stop supporting version 2 onion services later this year. Please see the deprecation F.A.Q. entry regarding Tor version 0.4.6. Migrate your services and update your bookmarks to version 3 onion services as soon as possible. The full changelog since Tor Browser 11.0a2: Android Update NoScript to 11.2.11 Bug 40176: TBA: sometimes I only see the banner and can’t tap on the address bar Bug 40185: Use NimbusDisabled Bug 40181: Remove V2 Deprecation banner on about:tor for Android Bug 40184: Rebase fenix patches to fenix v91.0.0-beta.5 Bug 40063: Move custom search providers Build System Android Bug 40331: Update components for mozilla91

  • Help Tor Smash Bugs: August 1-31!
    by Al Smith on July 27, 2021 at 1:17 pm

    Help Tor Smash Bugs: August 1-31! Al Smith July 27, 2021 The Bug Smash Fund is back for its third year! In 2019, we launched Tor’s Bug Smash Fund to raise money that would support our developers finding and fixing bugs in our software and to conduct routine maintenance. Maintenance isn’t a flashy new feature, and that makes it less interesting to many traditional funders, but it’s what keeps the reliable stuff working–and with your support, we’ve closed 370 Bug Smash Fund tickets. These bugs and issues ranged from anti-censorship development, testing, onion services, documentation and improvements, Tor Browser UX changes, and tooling for development. This work keeps Tor Browser, the Tor network, and the many tools that rely on Tor strong, safe, and running smoothly. And there’s so much more we can accomplish. Thirty-seven tickets tagged BugSmashFund are still open, and as you know, a big part of building software is ensuring that you can address issues when you find them. As such, starting August 1, every donation we receive during the month of August will count towards the Bug Smash Fund 2021. Your donation today to the Bug Smash Fund will help us: Find and fix security bugs. We can’t predict when bugs will happen, but it is inevitable that issues will arise. Our top priority is to smash these bugs as quickly as possible when they are discovered. Push emergency releases. Past examples include: Emergency security update to Tor Browser to handle a mistake in Mozilla’s signing infrastructure. (‘NoScript Temporarily Disabled in Tor Browser,’ 2019) and emergency release of Tor Browser, fixing an IP address leak issue caused by a bug in Firefox’s handling of file:// URLs. (‘Tor Browser 7.0.9 is released,’ 2017) Respond in the censorship arms race. We use the Bug Smash Fund to ensure that all people who need Tor can access it. This year, when Microsoft announced that it would shut down domain fronting attempts in Azure, we used the Bug Smash Fund to set up domain fronting with Fastly for Snowflake and Moat. There are many different ways to contribute to the Bug Smash Fund, and all of them count towards reaching this goal: Make a one-time donation (and get swag like Tor stickers and t-shirts in return) Donate in ten different cryptocurrencies Become a monthly donor and get your own Defenders of Privacy patch Make a contribution of $1,000 and join the major donor group Champions of Privacy Transfer your Open Collective gift card Use the hashtag #TorBugSmash to share the campaign Your support keeps Tor strong. Thank you for being part of the fight for privacy online.

  • New Release: Tor Browser 11.0a2
    by sysrqb on July 20, 2021 at 7:38 pm

    New Release: Tor Browser 11.0a2 sysrqb July 20, 2021 Tor Browser 11.0a2 is now available from the Tor Browser 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 Windows/macOS/Linux or Android release instead. This version updates Firefox to version 78.12.0esr on Windows, macOS, and Linux, and Firefox to version 90.1.1 on Android. This version includes important security updates to Firefox on Windows, macOS, and Linux, and Android. Warning: Tor Browser Alpha does not support version 2 onion services. Tor Browser (Stable) will stop supporting version 2 onion services later this year. Please see the deprecation F.A.Q. entry regarding Tor version 0.4.6. Migrate your services and update your bookmarks to version 3 onion services as soon as possible. The full changelog since Tor Browser 11.0a1: All Platforms Update HTTPS Everywhere to 2021.7.13 Windows + OS X + Linux Update Firefox to 78.12.0esr Bug 40497: Cannot set multiple pages as home pages in 10.5a17 Bug 40506: Saved Logins not available in 10.5 Bug 40507: Full update is not downloaded after applying partial update fails Bug 40510: open tabs get redirected to about:torconnect on restart Bug 40524: Update DuckDuckGo onion site URL in search preferences and onboarding Android Update Fenix to 90.1.1 Bug 40062: Update DuckDuckGo onion search plugin Bug 40177: Hide Tor icons in settings Build System All Platforms Update Go to 1.16.6

  • New Release: Tor Browser 10.5.3 (Android)
    by sysrqb on July 20, 2021 at 7:31 pm

    New Release: Tor Browser 10.5.3 (Android) sysrqb July 20, 2021 Tor Browser 10.5.3 is now available from the Tor Browser download page and also from our distribution directory. This version updates Firefox to 90.1.1. This version includes important security updates to Firefox. Warning: Tor Browser will stop supporting version 2 onion services later this year. Please see the previously published deprecation timeline. Migrate your services and update your bookmarks to version 3 onion services as soon as possible. The full changelog since Tor Browser 10.5.1: Android Update HTTPS Everywhere to 2021.7.13 Update Fenix to 90.1.1 Bug 40172: Find the Quit button Bug 40173: Rebase fenix patches to fenix v90.0.0-beta.6 Bug 40177: Hide Tor icons in settings Bug 40179: Show Snowflake bridge option on Release Bug 40180: Rebase fenix patches to fenix v90.1.1 Build System Android Bug 40312: Update components for mozilla90

  • Bug Smash Fund, Year 2: Progress Since February 2021
    by Al Smith on July 13, 2021 at 9:50 pm

    Bug Smash Fund, Year 2: Progress Since February 2021 Al Smith July 13, 2021 Last August, we asked you to help us fundraise during our second annual Bug Smash Fund campaign. This fund is designed to grow a healthy reserve earmarked for maintenance work, finding bugs, and smashing them—all tasks necessary to keep Tor Browser, the Tor network, and the many tools that rely on Tor strong, safe, and running smoothly. In 2020, despite the challenges of COVID-19 and event cancellations, you helped us to raise $106,709! We want to share an update on some of the work that the second year of the Bug Smash Fund has made possible. Since 2019, we’ve marked 410 tickets with BugSmashFund. As of today, 373 of those tickets have been closed, and 37 of them are still in progress. This year, we’ve used the Bug Smash Fund to work on continuous integration tooling, Tor Browser improvements, helping onion services providers defend against DDoS by migrating to v3 onion services, fixing bugs on GetTor, moving forward with Arti, and security fixes. We have also used the Bug Smash Fund to create a new status.torproject.org page, which will act as a landing place for network and service status updates. Thanks for supporting this work! Below is a list of some of the tickets we’ve closed since our last update in February 2021. Website We fixed several bugs on our main website (https://torproject.org).  On the new download page, the signature and the (?) link are not perceived as different Should we move anonbib to the Tor website? Update to v3 onion service links Censorship Analysis We tracked several censorship events in Iran, Venezuela and other countries. Venezuela blocks access to the Tor network BridgeDB We have a sponsored project to improve bridgeDB, but some bugs are not covered and were fixed with the Bug Smash Fund. bridgedb verifyHostname doesn’t check subjectAltName extension GetTor We are back into maintaining GetTor. It will be integrated into rdsys this year, but for now, we have GetTor running on its own. gettor not answering emails April 27 Onionoo We fixed a few bugs in the service that runs Relays Search. “AS” prefix missing from the as field in documents Possible for inconsistency between summary and details with AS number Add an ant task to update GeoIP resources Tor We fixed a variety of bugs on core tor with the Bug Smash Fund over the last several months. Bridges without geoip file report empty statistics ControlPort GETCONF does not recognize command aliases “GETINFO config-text” adds spurious DataDirectory, Log entries Tor uses Roaming (remote) %APPDATA% instead of %LOCALAPPDATA% junk log messages every time SETCONF changes the set of ORPorts Tor Windows service should be installed with the NetworkService account Tor log dates imprecise Fallback to resolving localhost when interface searches fail GETCONF provides incorrect value when undefined Received extra server info (size 0) Tor would bind ControlPort to public ip address if it has no localhost interface Directory Authorities should test reachability of relays in their family Jenkins Windows builders are currently broken Coverage flapping in hs_get_responsible_hsdirs() Some of our tests require internet connectivity / an IPv4 stack Remove ping ::1 from tor’s test-network-all and simplify the logic nondeterministic coverage of dirvote.c and shared_random.c rust protover doesn’t canonicalize adjacent and overlapping ranges rust protover_all_supported() accepts too-long protocol names Examples in CodingStandardsRust.md are wrong disparate duplicate subproto handling in protover handling double spaces in protover protover doesn’t forbid version zero Check uses of CMP_SEMANTIC for IP addresses Handle extreme values better in add_laplace_noise() sample_laplace_distribution should produce a valid result on 0.0 rep_hist_format_hs_stats() should add noise, then round sample_laplace_distribution() should take multiple random inputs Fix extra-info flags on fallbacks Do we need to chown AF_UNIX sockets? Use a better pattern for “create mutex if not already initialized” circuit_handle_first_hop assumes all one-hop circuits are directory circuits clear_status_flags_on_sybil might want to clear more flags compute_weighted_bandwidths() broken for dirauths Directory Authorities can crash client/relay by scrambling microdesc assignments connection_mark_unattached_ap_:  checking always true edge_has_sent_end zlib compression bomb warning in notices.log on a middle relay Find a working alternative to using MaxMind’s GeoLite2 databases Tor Browser We’ve fixed bugs in the Tor Browser building process, as well as closed two tickets related to Tor Browser itself: onion alias url rewrite is broken and document first party isolation for Tor researchers. We are also in the process of changing the repositories branch from “master” to “main,” and some of that work was done during this period. Thank you to everybody who made a contribution to the Bug Smash Fund. This work is critical in helping us to provide safer tools for millions of people around the world exercising their human rights to privacy and freedom online. If you’d like to make a contribution to the Bug Smash Fund, you can do so by making a gift at donate.torproject.org: just add “Bug Smash Fund” into the comment field, and we’ll make sure it’s directed to the right place.

  • New Release: Tor Browser 10.5.2 (Windows, macOS, Linux)
    by sysrqb on July 13, 2021 at 7:22 pm

    New Release: Tor Browser 10.5.2 (Windows, macOS, Linux) sysrqb July 13, 2021 Tor Browser 10.5.2 is now available from the Tor Browser download page and also from our distribution directory. This version updates Firefox to 78.12.0esr. This version includes important security updates to Firefox. Warning: Tor Browser will stop supporting version 2 onion services later this year. Please see the previously published deprecation timeline. Migrate your services and update your bookmarks to version 3 onion services as soon as possible. The full changelog since Tor Browser 10.5: Windows + OS X + Linux Update Firefox to 78.12.0esr Bug 40497: Cannot set multiple pages as home pages in 10.5a17 Bug 40507: Full update is not downloaded after applying partial update fails Bug 40510: open tabs get redirected to about:torconnect on restart

  • New Release: Tails 4.20
    by Tails on July 13, 2021 at 12:16 pm

    New Release: Tails 4.20 Tails July 13, 2021 Tor Connection assistant Tails 4.20 completely changes how to connect to the Tor network from Tails. After connecting to a local network, a Tor Connection assistant helps you connect to the Tor network. This new assistant is most useful for users who are at high risk of physical surveillance, under heavy network censorship, or on a poor Internet connection: It protects better the users who need to go unnoticed if using Tor could look suspicious to someone who monitors their Internet connection (parental control, abusive partner, school or work network, etc.). It allows people who need to connect to Tor using bridges to configure them without having to change the default configuration in the Welcome Screen. It helps first-time users understand how to connect to a local Wi-Fi network. It provides feedback while connecting to Tor and helps troubleshoot network problems. We know that this assistant is still far from being perfect, even if we have been working on this assistant since February. If anything is unclear, confusing, or not working as you would expect, please send your feedback to [email protected] (public mailing list). This first release of the Tor Connection assistant is only a first step. We will add more improvements to it in the coming months to: Save Tor bridges to the Persistent Storage (#5461) Help detect when Wi-Fi is not working (#14534) Detect if you have to sign in to the local network using a captive portal (#5785) Synchronize the clock to make it easier to use Tor bridges in Asia (#15548) Make it easier to learn about new Tor bridges (#18219, #15331) Changes and updates Update OnionShare from 1.3.2 to 2.2. This major update adds a feature to host a website accessible from a Tor onion service. Update KeePassXC from 2.5.4 to 2.6.2. This major update comes with a redesign of the interface. Update Tor Browser to 10.5.2. Update Thunderbird to 78.11.0. Update Tor to 0.4.5.9. Update the Linux kernel to 5.10.46. This should improve the support for newer hardware (graphics, Wi-Fi, and so on). Rename MAC address spoofing as MAC address anonymization in the Welcome Screen. Fixed problems Automatic upgrades Made the download of upgrades and the handling of errors more robust. (#18162) Display an error message when failing to check for available upgrades. (#18238) Tails Installer Made the display of the Reinstall button more robust. (#18300) Make the Install and Upgrade unavailable after a USB stick is removed. (#18346) For more details, read our changelog. Known issues Automatic upgrades are broken from Tails 4.14 and earlier. To upgrade from Tails 4.14 or earlier, you can either: Do a manual upgrade. Fix the automatic upgrade from a terminal. To do so: Start Tails and set up an administration password. In a terminal, execute the following command: torsocks curl –silent https://tails.boum.org/isrg-root-x1-cross-signed.pem | sudo tee –append /usr/local/etc/ssl/certs/tails.boum.org-CA.pem && systemctl –user restart tails-upgrade-frontend This command is a single command that wraps across several lines. Copy and paste the entire block at once and make sure that it executes as a single command. Approximately 30 seconds later, you should be prompted to upgrade to the latest version of Tails. If no prompt appears, you might already be running the latest version of Tails. See the list of long-standing issues. Get Tails 4.20 To upgrade your Tails USB stick and keep your persistent storage Automatic upgrades are broken from Tails 4.14 and earlier. See the known issue above. Automatic upgrades are available from Tails 4.14 or later to 4.20. You can reduce the size of the download of future automatic upgrades by doing a manual upgrade to the latest version. If you cannot do an automatic upgrade or if Tails fails to start after an automatic upgrade, please try to do a manual upgrade. To install Tails on a new USB stick Follow our installation instructions: Install from Windows Install from macOS Install from Linux The Persistent Storage on the USB stick will be lost if you install instead of upgrading. To download only If you don’t need installation or upgrade instructions, you can download Tails 4.20 directly: For USB sticks (USB image) For DVDs and virtual machines (ISO image) What’s coming up? Tails 4.21 is scheduled for August 10. Have a look at our roadmap to see where we are heading to. Support and feedback For support and feedback, visit the Support section on the Tails website.

  • New Release: Tor Browser 11.0a1 (Android Only)
    by sysrqb on July 12, 2021 at 7:26 pm

    New Release: Tor Browser 11.0a1 (Android Only) sysrqb July 12, 2021 Tor Browser 11.0a1 is now available from the Tor Browser 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 version updates Fenix to 90.0.0-beta.6. Warning: Tor Browser Alpha does not support version 2 onion services. Tor Browser (Stable) will stop supporting version 2 onion services later this year. Please see the deprecation F.A.Q. entry regarding Tor version 0.4.6. Migrate your services and update your bookmarks to version 3 onion services as soon as possible. The full changelog since Tor Browser 10.5a17: Android Bug 40172: Find the Quit button Bug 40173: Rebase fenix patches to fenix v90.0.0-beta.6 Bug 40179: Show Snowflake bridge option on Release Build System Android Bug 40312: Update components for mozilla90 Bug 40323: Remove unused gomobile project

  • Transparency, Openness, and Our 2020 Financials
    by Al Smith on July 9, 2021 at 5:00 pm

    Transparency, Openness, and Our 2020 Financials Al Smith July 09, 2021 Every year, as required by U.S. federal law for 501(c)(3) nonprofits, the Tor Project completes a Form 990, and as required by contractual obligations and state regulations, an independent audit of our financial statements. After completing standard audits for 2019-2020,* our federal tax filings and audit are both now available. We upload all of our tax documents and publish a blog post about these documents in order to be transparent. Transparency for a privacy project is not a contradiction: privacy is about choice, and we choose to be transparent in order to build trust and a stronger community. In this post, we aim to be very clear about where the Tor Project’s money comes from and what we do with it. This is how we operate in all aspects of our work: 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. This year’s version of the financial transparency post is a bit different than past iterations: we hope that by expanding each subsection of this post and adding more detail, you will have an even better understanding of the Tor Project’s funding, and that you will be able to read the audit and Form 990 documents on your own should you have more questions. *Reminder: We no longer tie our tax filings and our audits to the calendar year; instead our fiscal years run from July through June. We made this change in 2017 because following the calendar year meant that our fiscal years were ending right in the middle of fundraising season (December), making it harder to plan budgets. Fiscal Year 2019-2020 Summary The last few years have been bumpy financially for the Tor Project, but at the end of 2019 and beginning of 2020, we began stabilizing. You helped make this possible by contributing to an incredibly successful 2019 year-end campaign, raising more funds than we ever had before during a year-end campaign up to that point. We were looking towards rebuilding our reserves after having to use them to cover expenses in 2017 and 2018.  Then, of course, the COVID-19 pandemic changed the world. Individual donations took a drastic downturn, events (where we raise donations at booths) were canceled for the rest of the year, and foundations shifted their funding strategies to stabilize their current grantees. Some foundations even completely halted their giving for the year.  Despite all of these challenges, we ended the financial year (June 2020) in a stable place. Revenue & Support Tor’s total revenue and support in fiscal year 2019-2020 was a bit under $4.9 million. Take a look at page two of the audit: You can see that “Revenue and Support” is broken into five different categories in the audit documents: most categories are more or less self-explanatory, but let’s talk about in-kind contributions. In-kind contributions are donated services or goods–like translation completed by volunteers, website hosting, donated hardware, and contributed patches. This year, we counted $450,705 in donated services: that’s 2,490 hours of software development, 1,203,719 words translated, and roughly $96K in cloud hosting services. Clearly, Tor would not be possible without you. Thank you! Because in-kind contributions don’t equal actual money in the bank–but instead equate to value assigned to donated services and goods–think of the $450,705 in-kind contributions as the “Support” portion of the Revenue and Support category. Consider the remaining $4,400,782 in this category as the “Revenue.” In the 2019-2020 fiscal year, our “Revenue and Support” was less than the previous fiscal year by about $700,000. On the surface this might seem scary, but this reduction in revenue and support also comes with a reduction in expenses and a reversal of unsustainable spending of our reserves. Here’s a comparison, where you can see that in FY 2018-2019, we had to spend a significant amount of our reserves. In FY 2019-2020, we actually increased our assets slightly, despite all of the challenges related to COVID-19. Financial Year Income Expenses Change in Net Assets July 2018 – June 2019 $5,606,013 $6,188,913 ($582,900) July 2019 – June 2020 $4,851,487 $4,811,399 $40,088 Government Support We get a lot of questions (and see a lot of FUD) about how the U.S. government funds the Tor Project, so we want to make this as clear as possible, and show you where to find this information in the future (or for previous years) in these publicly-available documents. Let’s talk specifically about which parts of the U.S. government support Tor, and what kind of projects they fund. Below, you can see a screenshot from the Tor Project’s FY 2019-2020 Form 990 on page 42, where we’ve listed all of our U.S. government funders. You will find text like this in all of our Form 990s. Now, we’ll break down which projects are funded by each entity and link you to places in GitLab where we organize the work associated with this funding. U.S. State Department Bureau of Democracy, Human Rights, and Labor ($752,154) Project: Empowering Communities in the Global South to Bypass Censorship.  Description: This ongoing project’s goal is to empower human rights defenders in the Global South by improving censorship event detection and reporting, ensuring users have the best options for their needs to bypass censorship, and informing human rights defenders when censorship is happening and how to bypass it. National Science Foundation + Georgetown University ($98,727) Project: Expanding Research Frontiers with a Next-Generation Anonymous Communication Experimentation (ACE) Framework Description: This ongoing project’s goal is to develop a scalable and mature deterministic network simulator, capable of quickly and accurately simulating large networks such as Tor. This project builds on the Shadow Simulator. Open Technology Fund ($908,744) Project: Observing and Responding to Internet Censorship Around the World  Description: This completed project aimed to provide timely evidence of internet censorship events. Funding passed through the Tor Project to the Open Observatory of Network Interference (OONI) when they were still a team inside of the Tor Project, and not their own nonprofit organization as they are today.  Project: Onion Services (links to final project report, PDF) Description: This completed project brought v3 onion services in parity with v2, brought v3 support to Onion Balance, human readability of onion services addresses, and mechanisms (e.g., Onion Cannon) to better investigate DDoS attacks. Project: Tor Browser Security, Performance, & Usability Improvements. Description: This completed project funded the migration of Tor Browser for Android from ​Fennec to Fenix. Institute of Museum and Library Science + New York University ($101,549) Project: This funding passed through the Tor Project to Library Freedom Project to deliver the Library Freedom Institute.  Defense Advanced Research Projects Agency + Georgetown University Project: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR) Description: This ongoing project’s goal is to understand how to obfuscate communication in the presence of an adversary that controls the entire network,  by hiding all communications inside traffic generated by common applications. For even more about how government funding works for the Tor Project, consider reading our previous financial transparency posts, as well as Roger’s thorough comments on these posts. Other Grants & Contracts Of the remaining 47% of our revenue, about 26% comes from non-U.S. governments, foundations, other nonprofits, and corporations. Many of these contributions are in the form of restricted grants, which means we propose a project that is on our roadmap to a funder, they agree that this project is important, and we are funded to complete these projects. Some examples in this category include DIAL Open Source Center’s support of Tor Browser ESR migration work, Zcash Foundation’s support of our project to write the specs for Walking Onions, and RIPE NCC’s support of our work to improve IPv6 support on the Tor network. Also in this category are unrestricted funds, like support from Media Democracy Fund, Craig Newmark Fund, and FOSS Responders. These unrestricted funds are not tied to a specific project, which means we can use this funding to respond and develop our tools in a more agile way. Unrestricted funds also include contributions from corporations, and is where you will find membership dues from our members. In the 2019-2020 fiscal year, you’ll see contributions from our first two members, Avast and Mullvad! We haven’t listed every single entity you will see in our Form 990 in this blog post, but we hope you have a better understanding of what you might find in the Form 990. Please explore these documents to learn even more! Individual Contributions Individual contributions come in many forms: some people donate $5 to the Tor Project one time, some donate $100 every month, and some make large gifts annually. The common thread is that individual donations are unrestricted funds, and are the most important kind of support we receive. Unrestricted funds allow us to respond to censorship events, develop our tools in a more agile way, and ensure we have reserves to keep Tor strong in case of emergencies (like what happened in 2020, with COVID-19.) In the 2019-2020 fiscal year, you contributed $890,353 to the Tor Project in the form of one-time gifts and monthly donations. These gifts came in all different forms (including ten different cryptocurrencies, which are then converted to USD), and come together to equal our greatest individual fundraising year in our history. Thank you! Expenses OK, we’ve told you how we get funding (and which documents to look at to learn more). Now what do we do with that money? You can find that information on page four of this year’s audit. We break our expenses into three main categories:  Administration: costs associated with organizational administration, like salary for our Executive Director, office supplies, business insurance costs; Fundraising: costs associated with the fundraising program, like salary for fundraising staff, tools we use for fundraising, bank fees, postal mail supplies, swag; and  Program services: costs associated with making Tor and supporting the people who use it, including application, network, UX, metrics, and community staff salaries; contractor salaries; and IT costs. In the 2019-2020 fiscal year, 90.4% of our expenses were associated with program services. That means that a very significant portion of our budget goes directly into building Tor and making it better. Next comes fundraising at 6.4% and administration at 3.2%.  According to Charity Navigator, technology nonprofits for which program services make up more than 82.5% of their expenses receive the highest “financial health” score in their ranking system. This means that we’re meeting and significantly exceeding the “industry best” for tech nonprofits. We’re proud to show that our work is both efficient and effective. Ultimately, like Roger has written in many past versions of this blog post, it’s very important to remember the big picture: Tor’s budget is modest considering our small staff and global impact. And it’s also critical to remember that our annual revenue is utterly dwarfed by what our adversaries spend to make the world a more dangerous and less free place. In closing, we are extremely grateful for all of our donors and supporters. You make this work possible, and we hope this expanded version of our financial transparency post sheds more light on how the Tor Project raises money and how we spend it. Remember, that beyond making a donation, there are other ways to get involved, including volunteering and running a Tor relay!

  • Announcing Arti, a pure-Rust Tor implementation
    by nickm on July 8, 2021 at 3:48 pm

    Announcing Arti, a pure-Rust Tor implementation nickm July 08, 2021 Greetings! Today I’m happy to announce a new era in Tor implementation. Over the past year or so, we’ve been working on “Arti”, a project to rewrite Tor in Rust. Thanks to funding from Zcash Open Major Grants (ZOMG), we can finally put the Arti project up in our priorities list, and devote more time to it. Below I’ll talk about why we’re doing this project, what it means for Tor users and operators, where it’s going in the future, and how people can help. A little background Tor is a set of protocols to provide anonymity, privacy, and censorship resistance on the Internet. Tor is also a program (in C) that provides client-side and server-side implementations of those protocols. We started Tor back around 2002, based on earlier Onion Routing designs from the mid-1990s. In 2006, we incorporated the Tor Project as a nonprofit charity. Since then, Tor has grown to handle millions of users around the world. Why write Tor in Rust? Today’s Tor is written in the C programming language. Although C is venerable and ubiquitous, it’s notoriously error-prone to use, and its lack of high-level features make many programming tasks more complex than they’d be in a more modern language. For us, these problems mean that programming in C is a slow and painstaking process. Everything we write takes more code than we’d like it to, and we need to double-check even the safest-looking code to make sure it doesn’t fall prey to any of C’s list of enormous gotchas. This slows us down seriously, and increases the cost of adding new features. Rust seems like the clearest way out of our bind. It’s a high-level language, and significantly more expressive than C. What’s more, it’s got some really innovative features that let the language enforce certain safety properties at compile-time. To a first approximation, if the code compiles, and it isn’t explicitly marked as “unsafe”, then large categories of bugs are supposed to be impossible. That’s a huge win for us in programming and debugging time, and a huge win for users in security and reliability. Since 2016, we’ve been tracking all the security bugs that we’ve found in Tor, and it turns out that at least half of them were specifically due to mistakes that should be impossible in safe Rust code. Example: multithreaded crypto Here’s a case where Rust’s safety can really help us. For years now, we’ve wanted to split Tor’s relay cryptography across multiple CPU cores, but we’ve run into trouble. C’s support for thread-safety is quite fragile, and it is very easy to write a program that looks safe to run across multiple threads, but which introduces subtle bugs or security holes. If one thread accesses a piece of state at the same time that another thread is changing it, then your whole program can exhibit some truly confusing and bizarre bugs. But in Rust, this kind of bug is easy to avoid: the same type system that keeps us from writing memory unsafety prevents us from writing dangerous concurrent access patterns. Because of that, Arti’s circuit cryptography has been multicore from day 1, at very little additional programming effort. Why a full rewrite? At one point, we had hoped to slowly replace Tor’s C code with Rust, one piece at a time. That hasn’t worked out for us, however. Our problem here is that the modules in our existing C code are not terribly well separated from one another: most modules are reachable from most other modules. That makes it hard for us to rewrite our code one module at a time, without first untangling it to be more modular. And untangling the code is risky, for all the same reasons that working in C is typically risky. With a rewrite, we figured that we can keep our existing C code stable and make only minimal changes to it, while building up a working base of Rust code to serve as a basis for future development. (And while we’re writing a new implementation, we can clean up design issues that have been hard to fix in C. For example, the complicated structure of the C code has made it hard to adopt for embedding into other applications. But with our Arti rewrite, we can take embedding into account from the start, to help support applications down the road.) What can Arti do today? What features are missing? First off: Don’t use Arti for real privacy yet. Arti doesn’t yet run as a relay at all. It doesn’t support Tor’s anti-censorship features yet, and it can’t connect to onion services yet. Finally, note that today’s Arti is missing several key security features for privacy: you shouldn’t use it for browsing if you have actual privacy needs at all. So what can Arti do? Right now, Arti can successfully bootstrap, run as a SOCKS proxy, and connect over the Tor network. It has an (unstable) API that you can use to embed it in other Rust programs, and give them support for connections over the Tor network. What are the next steps for Arti? Thanks to funding from ZOMG, we’re going to try bring Arti to a production-quality client implementation over the next year and a half. In our first phase, we’re focusing on the missing security features that we need in order to get Arti as secure as Tor. We estimate we’ll be done with this in October of this year. This phase will probably move the most slowly, since we’re ramping up our Rust development capacity (and getting better at Rust!), and as we’re finishing up some existing commitments. In our second phase, we’ll focus on all the features needed for seamless embedding. We’ll add missing features for efficiency and responsiveness, and add APIs for bootstrap reporting and other functionality that applications need to give a good user experience. We estimate we’ll finish this around March of 2022. In our third phase, we’ll work to get Arti ready for production client use. We also expect that this will involve a lot of fine-tuning, experimentation, and fixing issues in response to early experimentation and user experience. We expect we’ll finish this around September of 2022. And in our fourth phase, we’ll be working on anti-censorship features (including bridges and pluggable transports). We think we can do that in a single additional month, wrapping up around October of 2022. Beyond that, the plans are unwritten (and so far, unfunded). The next priority will probably be programming support for v3 onion services, and after that, all the other missing client-side features that users need. And then? We also want support for running a Tor Relay in Rust. That will require a great deal of additional effort, but it should help significantly with the network’s performance, reliability, security, and pace of development. What does this mean for the existing C Tor implementation? Depending on whether you’re an optimist, you might say that that the C Tor code isn’t going anywhere soon. Or you might say that its days are numbered. In order to make the time to work on Arti, we need to devote our resources in that direction. We expect that in the coming years, we will spend more and more time programming in Rust, and less in C. Eventually, once our Rust implementation of Tor is a good replacement for our C implementation, we will stop adding new features to the C implementation, and eventually drop support for it entirely. But that’s far off, for now. At present, we’re going to continue supporting and developing our C Tor as a client and relay. We expect that the pace of new features in C will slow, but we will continue fixing issues, shipping bugfixes, and solving important problems in our C code, until Rust is ready to replace it entirely. We will work to keep C Tor users secure, safe, and private, until it is finally ready to be replaced. How can I try out Arti? Remember, don’t try it yet if you want security or privacy, since it won’t give you those. If you’d like to try Arti with TorBrowser, you can read the instructions in our CONTRIBUTING.md file. They assume that you have cargo installed, and that you know how to build rust programs. If you’d like to write a Rust program using Arti, have a look at the arti-tor-client crate. For now, you’re probably better off using ours instead of the one on crates.io. (Remember, these APIs aren’t stable, and are subject to change without warning.) How can I follow along with development? We’re going to be posting updates in a bunch of different ways, to see what works best for everybody. First off, we’ll be posting regular updates (more technically and more frequently than you’d really want from this blog) on the tor-dev mailing list, and eventually on a dedicated website. Second, we’re going to be recording some of our regular meetings and posting them on the Tor Project’s YouTube channel in a dedicated playlist. There we’ll be talking about what to work on next, how to organize and schedule, and generally keeping track of pace and priorities. Third, we hope to be hosting regular public hackathons and programming sessions for interested developers. More information as it develops! How can I help? For now, we most need developers and documentation — especially you’re already familiar with Rust or Tor, but even if you’re not. The CONTRIBUTING.md document has a few suggestions of where to start, but it’s still pretty new. (Are you any good at writing “How can I help” documents?)

  • New Release: Tor Browser 10.5.1 (Android Only)
    by sysrqb on July 7, 2021 at 5:27 pm

    New Release: Tor Browser 10.5.1 (Android Only) sysrqb July 07, 2021 Tor Browser 10.5.1 is now available from the Tor Browser download page and also from our distribution directory. This version is a bugfix for Android Tor Browser 10.5. Warning: Tor Browser will stop supporting version 2 onion services later this year. Please see the previously published deprecation timeline. Migrate your services and update your bookmarks to version 3 onion services as soon as possible. The full changelog since Tor Browser 10.5: Android Bug 40324: Change Fenix variant to Release

  • New Release: Tor Browser 10.5
    by Antonela on July 6, 2021 at 4:56 pm

    New Release: Tor Browser 10.5 Antonela July 06, 2021 Tor Browser 10.5 is now available from the Tor Browser download page and also from our distribution directory. This new Tor Browser release is focused on improving the internet access of users connecting through Tor in censored contexts. What’s new? V2 Onion Services Deprecation As we announced last year, v2 onion services will be completely unreachable once Tor Browser moves to Tor 0.4.6.x in October 2021. From now until then, Tor Browser will warn you when visiting a v2 onion site of its upcoming deprecation. Snowflake is now available as a bridge With Snowflake, censored users can rely on proxies run by volunteers to connect to the internet. During Q1 this year, the UX team ran a survey on Tor Browser Alpha to better understand Snowflake’s user experience. The survey received 1,795 complete responses, of which 726 participants confirmed they use Snowflake as a pluggable transport. The majority of Snowflake users who completed the survey began using Tor Browser several times a week within the past year. 75% of users had a positive view of Snowflake, although many experienced connection troubles and slow speeds while browsing. These facts and the stable network of volunteers allow us to make it available on this release. › Read more about Snowflake’s stable release Improving the user experience of connecting to Tor Tor Launcher has acted as the options panel for advanced Tor network configurations over the years. It also serves as a control point for users who are in censored networks. The UX and the Anti-Censorship teams joined efforts to improve the connecting flow for Tor Browser users. This release is the first in the upcoming series of helping censored users seamlessly access the open internet by simplifying the connection flow, detecting censorship and providing bridges. › Read more about the new connection experience Known Issues Tor Browser 10.5 comes with a number of known issues: Cannot set multiple pages as home pages in 10.5a17 – tpo/applications/tor-browser#40497 TBA: sometimes I only see the banner and can’t tap on the address bar – tpo/applications/fenix#40176 TBA: Investigate Image Upload – tpo/applications/fenix#40110 TBA: Find the Quit button – tpo/applications/fenix#40172 Two new-tab options shown on urlbar long-press – tpo/applications/fenix#40174 Tor Browser has two default bridges that share a fingerprint, and Tor ignores one – tpo/applications/tor-browser#40242 TBA: “Proxy Server Refused Connection” when you open a link in Tor when it hasn’t been initialised. – tpo/applications/fenix#40103 TBA: White screen when changing system theme – tpo/applications/fenix#40115 Change Fenix variant to Release – tpo/applications/tor-browser-build#40324 Saved Logins not available in 10.5 – tpo/applications/tor-browser#40506 Open tabs get redirected to about:torconnect on restart – tpo/applications/tor-browser#40510   Changelog The full changelog since Tor Browser 10.0.18 All Platforms Update NoScript to 11.2.9 Update Tor Launcher to 0.2.30 Translations update Bug 25483: Provide Snowflake based on Pion for Windows, macOS, and Linux Bug 33761: Remove unnecessary snowflake dependencies Bug 40064: Bump libevent to 2.1.12 Bug 40137: Migrate https-everywhere storage to idb Bug 40261: Bump versions of snowflake and webrtc Bug 40263: Update domain front for Snowflake Bug 40302: Update version of snowflake Bug 40030: DuckDuckGo redirect to html doesn’t work Windows + OS X + Linux Bug 27476: Implement about:torconnect captive portal within Tor Browser [tor-browser] Bug 32228: Bookmark TPO support domains in Tor Browser Bug 33803: Add a secondary nightly MAR signing key [tor-browser] Bug 33954: Consider different approach for Bug 2176 Bug 34345: “Don’t Bootstrap” Startup Mode Bug 40011: Rename tor-browser-brand.ftl to brand.ftl Bug 40012: Fix about:tor not loading some images in 82 Bug 40138: Move our primary nightly MAR signing key to tor-browser Bug 40209: Implement Basic Crypto Safety Bug 40428: Correct minor Cryptocurrency warning string typo Bug 40429: Update Onboarding for 10.5 Bug 40455: Block or recover background requests after bootstrap Bug 40456: Update the SecureDrop HTTPS-Everywhere update channel Bug 40475: Include clearing CORS preflight cache Bug 40478: Onion alias url rewrite is broken Bug 40484: Bootstrapping page show Quickstart text Bug 40490: BridgeDB bridge captcha selection is broken in alpha Bug 40495: Onion pattern is focusable by click on about:torconnect Bug 40499: Onion Alias doesn’t work with TOR_SKIP_LAUNCH Android Bug 30318: Integrate snowflake into mobile Tor Browser Bug 40206: Disable the /etc/hosts parser Linux Bug 40089: Remove CentOS 6 support for Tor Browser 10.5 Build System All Platforms Update Go to 1.15.13 Bug 23631: Use rootless containers [tor-browser-build] Bug 33693: Change snowflake and meek dummy address [tor-browser] Bug 40016: getfpaths is not setting origin_project Bug 40169: Update apt package cache after calling pre_pkginst, too Bug 40194: Remove osname part in cbindgen filename Windows + OS X + Linux Bug 40081: Build Mozilla code with –enable-rust-simd Bug 40104: Use our TMPDIR when creating our .mar files Bug 40133: Bump Rust version for ESR 78 to 1.43.0 Bug 40166: Update apt cache before calling pre_pkginst in container-image config Android Bug 28672: Android reproducible build of Snowflake Bug 40313: Use apt-get to install openjdk-8 .deb files with their dependencies Windows Bug 34360: Bump binutils to 2.35.1 Bug 40131: Remove unused binutils patches Linux Bug 26238: Move to Debian Jessie for our Linux builds Bug 31729: Support Wayland Bug 40041: Remove CentOS 6 support for 10.5 series Bug 40103: Add i386 pkg-config path for linux-i686 Bug 40112: Strip libstdc++ we ship Bug 40118: Add missing libdrm dev package to firefox container Bug 40235: Bump apt for Jessie containers   Give Feedback If you find a bug or have a suggestion for how we could improve this release, please let us know. Thanks to all of the teams across Tor, and the many volunteers, who contributed to this release. Updates: 2021-07-06 1900 UTC: Due to Bug 40324, Android Tor Browser 10.5 should not be installed. 2021-07-06 20:50 UTC: We are aware of issues related to saved passwords becoming unavailable after upgrading to Tor Browser 10.5. Please see tpo/applications/tor-browser#40506 for more information about the investigation. 2021-07-07 18:00 UTC: Tor Browser 10.5.1 is now available for Android as a fix for Bug 40324.

  • New stable release: Tor 0.4.6.6
    by nickm on June 30, 2021 at 4:14 pm

    New stable release: Tor 0.4.6.6 nickm June 30, 2021 We have a new stable release today. If you build Tor from source, you can download the source code for 0.4.6.6 on the download page. Tor 0.4.6.6 makes several small fixes on 0.4.6.5, including one that allows Tor to build correctly on older versions of GCC. You should upgrade to this version if you were having trouble building Tor 0.4.6.5; otherwise, there is probably no need. Changes in version 0.4.6.6 – 2021-06-30 Minor bugfixes (compilation): Fix a compilation error when trying to build Tor with a compiler that does not support const variables in static initializers. Fixes bug 40410; bugfix on 0.4.6.5. Suppress a strict-prototype warning when building with some versions of NSS. Fixes bug 40409; bugfix on 0.3.5.1-alpha. Minor bugfixes (testing): Enable the deterministic RNG for unit tests that covers the address set bloomfilter-based API’s. Fixes bug 40419; bugfix on 0.3.3.2-alpha.

  • New Release: Tor Browser 10.5a17
    by sysrqb on June 28, 2021 at 10:33 pm

    New Release: Tor Browser 10.5a17 sysrqb June 28, 2021 Tor Browser 10.5a17 is now available from the Tor Browser 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 version updates Tor to 0.4.6.5. This version is the last planned version before Tor Browser 10.5 is considered stable. Please report any bugs as soon as possible. In particular, any bugs in the new initial connect screen Warning: Tor Browser Alpha does not support version 2 onion services. Tor Browser (Stable) will stop supporting version 2 onion services later this year. Please see the deprecation F.A.Q. entry regarding Tor version 0.4.6. Migrate your services and update your bookmarks to version 3 onion services as soon as possible. The full changelog since Tor Browser 10.5a16: All Platforms Update NoScript to 11.2.9 Update Tor to 0.4.6.5 Update Tor Launcher to 0.2.29 Windows + OS X + Linux Bug 34345: “Don’t Bootstrap” Startup Mode Bug 40302: Update version of snowflake Bug 40455: Block or recover background requests after bootstrap Bug 40456: Update the SecureDrop HTTPS-Everywhere update channel Bug 40475: Include clearing CORS preflight cache Bug 40478: Onion alias url rewrite is broken Build System All Platforms Update Go to 1.15.13 Android Bug 40313: Use apt-get to install openjdk-8 .deb files with their dependencies

  • Improving the user experience of connecting to Tor in Tor Browser 10.5
    by Antonela on June 24, 2021 at 1:53 pm

    Improving the user experience of connecting to Tor in Tor Browser 10.5 Antonela June 24, 2021 During the past few years, the UX team has been working on qualitatively improving the entire Tor Browser user journey: from discovering to finding, downloading, installing, starting, and browsing; we released a seamless and familiar experience for our largest user base. Tor Browser 9.5 was an entire reshaping of the experience for users reaching onion sites, Tor Browser 9.0 and 8.0 shipped an improved experience for core legacy issues, and Tor Browser 8.5 was a rebranded release. However, users continue to report that launching Tor Browser for the first time is an abrasive experience. Our user research program in the Global South has shed light on how users experiment when confronted with pain points while connecting to Tor. Censored users have also explicitly mentioned how confusing they find the process of copying a bridge address from a webpage and then pasting that address into the browser interface. During our interviews in late 2020, a journalist living in Hong Kong said, “Using bridges is a very manual process.” Additionally, users have specifically reported that they find Tor Launcher confusing. Research exposed these pain points and has demonstrated how confusion caused by cognitive overload delays the user’s decision-making flow. Known issues with Tor Launcher, like the time gap between Tor Launcher and the main browser window opening after first-time installation, has left some users disappointed. In response, the growing ecosystem of Tor apps have opted to embed the connection experience in their UI instead, like you can see in Brave’s Private Windows with Tor or OnionShare. Our findings have informed the development of a new iteration of Tor Browser that focuses on improving the flow users follow when connecting to Tor for the first time and on subsequent uses by removing the Tor Launcher UI, making Tor bootstrapping automatic, and relying on a better UI embedded in the main browser screen to provide visual feedback. We are also working on improving the censored user’s experience by designing a user flow that will detect censorship and suggest and provide bridges to connect to the Tor network successfully.     The journey to improve the user experience of connecting to the Tor network starts with Tor Browser 10.5, which will be released later this month. This release is the first in an upcoming series of releases helping censored users seamlessly access the open internet.     We would love to hear your thoughts about this release. Feel free to open a ticket anonymously or email the tor-ux mailing list.  

  • New Release: Tor Browser 10.0.18
    by sysrqb on June 21, 2021 at 2:00 pm

    New Release: Tor Browser 10.0.18 sysrqb June 21, 2021 Tor Browser 10.0.18 is now available from the Tor Browser download page and also from our distribution directory. This version updates Tor to 0.4.5.9, including important security fixes. In addition, on Android, this version updates Firefox to 89.1.1, and NoScript to 11.2.8 This version includes important security updates to Firefox for Android. Warning: Tor Browser will stop supporting version 2 onion services later this year. Please see the previously published deprecation timeline. Migrate your services and update your bookmarks to version 3 onion services as soon as possible. The full changelog since Desktop Tor Browser 10.0.17 and Android Tor Browser 10.0.16: All Platforms Update Tor to 0.4.5.9 Android Update Fenix to 89.1.1 Update NoScript to 11.2.8 Bug 40055: Rebase android-componets patches on 75.0.22 for Fenix 89 Bug 40165: Announce v2 onion service deprecation on about:tor Bug 40166: Hide “Normal” tab (again) and Sync tab in TabTray Bug 40167: Hide “Save to Collection” in menu Bug 40169: Rebase fenix patches to fenix v89.1.1 Bug 40170: Error building tor-browser-89.1.1-10.5-1 Bug 40432: Prevent probing installed applications Bug 40470: Rebase 10.0 patches onto 89.0 Build System Android Bug 40290: Update components for mozilla89-based Fenix

  • Internet Freedom, Privacy, & LGBTQIA+ Human Rights
    by Al Smith on June 14, 2021 at 5:14 pm

    Internet Freedom, Privacy, & LGBTQIA+ Human Rights Al Smith June 14, 2021 Every June, we recognize Pride month because internet freedom and the human rights of LGBTQIA+ people go hand in hand. LGBTQIA+ people have the right to access information, resources, and community relevant to their identities without being tracked, surveilled, censored, or persecuted—but in many parts of the world, governments block LGBTQIA+ content and punish people who engage with it. In Russia, people face fines, prison sentences, intimidation, and violence for posting LGBTQIA+ content. In 2020, an activist was fined 75,000 rubles for posting a photo with the words, “Family is where the Love is. Support LGBT+ families.”  In Indonesia, LGBTQIA+ content, services, apps, and even emojis depicting LGBTQIA+ themes are frequently blocked or removed from app stores, with big tech complying with demands to censor this content. In 2018, Indonesian authorities purchased surveillance tools to track LGBTQIA+ rights activists. In Uganda, the LGBTQIA+ community is the target of regular technical attacks. Activists are hacked and surveilled, and attackers use content from hacked accounts to blackmail LGBTQIA+ people in the spotlight.  In the United States, public schools are required by federal law to use software to block pornographic websites, but schools often use that software to block sites that discuss LGBTQIA+ issues and resources that are not sexually explicit in any way. In Egypt, authories used the social networking app Grindr to track down and persecute LGBTQIA+ people by using fake profiles to gather evidence that is used to imprison, torture, and prosecute LGBTQIA+ people for “illegal sexual behavior.” Globally, many LGBTQIA+ people need privacy and censorship circumvention tools like Tor to communicate with their peers, find important resources, or fight for their rights without facing violence. This is one of the many reasons why we do what we do at the Tor Project, and it’s the reason we monitor the availability of LGBTQ+ sites in OONI tests, so we can better understand which countries are censoring these sites and who needs circumvention technology. (You can help monitor internet censorship, including against LGBTQIA+ sites, by running OONI Probe.) That’s why we travel to countries where governments outlaw or punish being LGBTQIA+ and lead workshops for community organizations about how to protect their privacy online. That’s why we partner with LGBTQIA+ groups to ensure that we’re learning about how they use privacy tech, and what they need from Tor in order to stay safe when using the internet. Pride and privacy go hand in hand. This June and year round, the Tor Project stands in solidarity with the LGBTQIA+ community. Happy Pride! 

  • New stable security releases: 0.3.5.15, 0.4.4.9, 0.4.5.9, 0.4.6.5
    by nickm on June 14, 2021 at 3:35 pm

    New stable security releases: 0.3.5.15, 0.4.4.9, 0.4.5.9, 0.4.6.5 nickm June 14, 2021 After months of work, we have a new stable release series! If you build Tor from source, you can download the source code for 0.4.6.5 on the download page. Packages should be available within the next several weeks, with a new Tor Browser around the end of the week. Because this release includes security fixes, we are also releasing updates for our other supported releases. You can find their source at https://dist.torproject.org: 0.3.5.15 (gpg signature) (ChangeLog) 0.4.4.9 (gpg signature) (ChangeLog) [Note that 0.4.4.9 hits end-of-life tomorrow; this is the last supported 0.4.4.9 release.] 0.4.5.9 (gpg signature) (ChangeLog) Tor 0.4.6.5 is the first stable release in its series. The 0.4.6.x series includes numerous features and bugfixes, including a significant improvement to our circuit timeout algorithm that should improve observed client performance, and a way for relays to report when they are overloaded. This release also includes security fixes for several security issues, including a denial-of-service attack against onion service clients, and another denial-of-service attack against relays. Everybody should upgrade to one of 0.3.5.15, 0.4.4.9, 0.4.5.9, or 0.4.6.5. Below are the changes since 0.4.5.8. For a list of changes since 0.4.6.4-rc, see the ChangeLog file. Changes in version 0.4.6.5 – 2021-06-14 Major bugfixes (security): Don’t allow relays to spoof RELAY_END or RELAY_RESOLVED cell on half-closed streams. Previously, clients failed to validate which hop sent these cells: this would allow a relay on a circuit to end a stream that wasn’t actually built with it. Fixes bug 40389; bugfix on 0.3.5.1-alpha. This issue is also tracked as TROVE-2021- 003 and CVE-2021-34548. Major bugfixes (security, defense-in-depth): Detect more failure conditions from the OpenSSL RNG code. Previously, we would detect errors from a missing RNG implementation, but not failures from the RNG code itself. Fortunately, it appears those failures do not happen in practice when Tor is using OpenSSL’s default RNG implementation. Fixes bug 40390; bugfix on 0.2.8.1-alpha. This issue is also tracked as TROVE-2021-004. Reported by Jann Horn at Google’s Project Zero.   Major bugfixes (security, denial of service): Resist a hashtable-based CPU denial-of-service attack against relays. Previously we used a naive unkeyed hash function to look up circuits in a circuitmux object. An attacker could exploit this to construct circuits with chosen circuit IDs, to create collisions and make the hash table inefficient. Now we use a SipHash construction here instead. Fixes bug 40391; bugfix on 0.2.4.4-alpha. This issue is also tracked as TROVE-2021-005 and CVE-2021-34549. Reported by Jann Horn from Google’s Project Zero. Fix an out-of-bounds memory access in v3 onion service descriptor parsing. An attacker could exploit this bug by crafting an onion service descriptor that would crash any client that tried to visit it. Fixes bug 40392; bugfix on 0.3.0.1-alpha. This issue is also tracked as TROVE-2021-006 and CVE-2021-34550. Reported by Sergei Glazunov from Google’s Project Zero. Major features (control port, onion services): Add controller support for creating version 3 onion services with client authorization. Previously, only v2 onion services could be created with client authorization. Closes ticket 40084. Patch by Neel Chauhan. Major features (directory authority): When voting on a relay with a Sybil-like appearance, add the Sybil flag when clearing out the other flags. This lets a relay operator know why their relay hasn’t been included in the consensus. Closes ticket 40255. Patch by Neel Chauhan. Major features (metrics): Relays now report how overloaded they are in their extrainfo documents. This information is controlled with the OverloadStatistics torrc option, and it will be used to improve decisions about the network’s load balancing. Implements proposal 328; closes ticket 40222. Major features (relay, denial of service): Add a new DoS subsystem feature to control the rate of client connections for relays. Closes ticket 40253. Major features (statistics): Relays now publish statistics about the number of v3 onion services and volume of v3 onion service traffic, in the same manner they already do for v2 onions. Closes ticket 23126. Major bugfixes (circuit build timeout): Improve the accuracy of our circuit build timeout calculation for 60%, 70%, and 80% build rates for various guard choices. We now use a maximum likelihood estimator for Pareto parameters of the circuit build time distribution, instead of a “right-censored estimator”. This causes clients to ignore circuits that never finish building in their timeout calculations. Previously, clients were counting such unfinished circuits as having the highest possible build time value, when in reality these circuits most likely just contain relays that are offline. We also now wait a bit longer to let circuits complete for measurement purposes, lower the minimum possible effective timeout from 1.5 seconds to 10ms, and increase the resolution of the circuit build time histogram from 50ms bin widths to 10ms bin widths. Additionally, we alter our estimate Xm by taking the maximum of the top 10 most common build time values of the 10ms histogram, and compute Xm as the average of these. Fixes bug 40168; bugfix on 0.2.2.14-alpha. Remove max_time calculation and associated warning from circuit build timeout ‘alpha’ parameter estimation, as this is no longer needed by our new estimator from 40168. Fixes bug 34088; bugfix on 0.2.2.9-alpha. Major bugfixes (signing key): In the tor-gencert utility, give an informative error message if the passphrase given in `–create-identity-key` is too short. Fixes bug 40189; bugfix on 0.2.0.1-alpha. Patch by Neel Chauhan. Minor features (bridge): We now announce the URL to Tor’s new bridge status at https://bridges.torproject.org/ when Tor is configured to run as a bridge relay. Closes ticket 30477. Minor features (build system): New “make lsp” command to auto generate the compile_commands.json file used by the ccls server. The “bear” program is needed for this. Closes ticket 40227. Minor features (client): Clients now check whether their streams are attempting to re-enter the Tor network (i.e. to send Tor traffic over Tor), and close them preemptively if they think exit relays will refuse them for this reason. See ticket 2667 for details. Closes ticket 40271. Minor features (command line): Add long format name “–torrc-file” equivalent to the existing command-line option “-f”. Closes ticket 40324. Patch by Daniel Pinto. Minor features (command-line interface): Add build informations to `tor –version` in order to ease reproducible builds. Closes ticket 32102. When parsing command-line flags that take an optional argument, treat the argument as absent if it would start with a ‘-‘ character. Arguments in that form are not intelligible for any of our optional-argument flags. Closes ticket 40223. Allow a relay operator to list the ed25519 keys on the command line by adding the `rsa` and `ed25519` arguments to the –list-fingerprint flag to show the respective RSA and ed25519 relay fingerprint. Closes ticket 33632. Patch by Neel Chauhan. Minor features (compatibility): Remove an assertion function related to TLS renegotiation. It was used nowhere outside the unit tests, and it was breaking compilation with recent alpha releases of OpenSSL 3.0.0. Closes ticket 40399. Minor features (control port, stream handling): Add the stream ID to the event line in the ADDRMAP control event. Closes ticket 40249. Patch by Neel Chauhan. Minor features (dormant mode): Add a new ‘DormantTimeoutEnabled’ option to allow coarse-grained control over whether the client ever becomes dormant from inactivity. Most people won’t need this. Closes ticket 40228. Add a new ‘DormantTimeoutEnabled’ option for coarse-grained control over whether the client can become dormant from inactivity. Most people won’t need this. Closes ticket 40228. Minor features (geoip data): Update the geoip files to match the IPFire Location Database, as retrieved on 2021/06/10. Minor features (logging): Edit heartbeat log messages so that more of them begin with the string “Heartbeat: “. Closes ticket 40322; patch from ‘cypherpunks’. Change the DoS subsystem heartbeat line format to be more clear on what has been detected/rejected, and which option is disabled (if any). Closes ticket 40308. In src/core/mainloop/mainloop.c and src/core/mainloop/connection.c, put brackets around IPv6 addresses in log messages. Closes ticket 40232. Patch by Neel Chauhan. Minor features (logging, diagnostic): Log decompression failures at a higher severity level, since they can help provide missing context for other warning messages. We rate-limit these messages, to avoid flooding the logs if they begin to occur frequently. Closes ticket 40175. Minor features (onion services): Add a warning message when trying to connect to (no longer supported) v2 onion services. Closes ticket 40373. Minor features (performance, windows): Use SRWLocks to implement locking on Windows. Replaces the “critical section” locking implementation with the faster SRWLocks, available since Windows Vista. Closes ticket 17927. Patch by Daniel Pinto. Minor features (protocol, proxy support, defense in depth): Close HAProxy connections if they somehow manage to send us data before we start reading. Closes another case of ticket 40017. Minor features (tests, portability): Port the hs_build_address.py test script to work with recent versions of python. Closes ticket 40213. Patch from Samanta Navarro. Minor features (vote document): Add a “stats” line to directory authority votes, to report various statistics that authorities compute about the relays. This will help us diagnose the network better. Closes ticket 40314. Minor bugfixes (build): The configure script now shows whether or not lzma and zstd have been used, not just if the enable flag was passed in. Fixes bug 40236; bugfix on 0.4.3.1-alpha. Minor bugfixes (compatibility): Fix a failure in the test cases when running on the “hppa” architecture, along with a related test that might fail on other architectures in the future. Fixes bug 40274; bugfix on 0.2.5.1-alpha. Minor bugfixes (compilation): Fix a compilation warning about unused functions when building with a libc that lacks the GLOB_ALTDIRFUNC constant. Fixes bug 40354; bugfix on 0.4.5.1-alpha. Patch by Daniel Pinto. Minor bugfixes (consensus handling): Avoid a set of bugs that could be caused by inconsistently preferring an out-of-date consensus stored in a stale directory cache over a more recent one stored on disk as the latest consensus. Fixes bug 40375; bugfix on 0.3.1.1-alpha. Minor bugfixes (control, sandbox): Allow the control command SAVECONF to succeed when the seccomp sandbox is enabled, and make SAVECONF keep only one backup file to simplify implementation. Previously SAVECONF allowed a large number of backup files, which made it incompatible with the sandbox. Fixes bug 40317; bugfix on 0.2.5.4-alpha. Patch by Daniel Pinto. Minor bugfixes (directory authorities, voting): Add a new consensus method (31) to support any future changes that authorities decide to make to the value of bwweightscale or maxunmeasuredbw. Previously, there was a bug that prevented the authorities from parsing these consensus parameters correctly under most circumstances. Fixes bug 19011; bugfix on 0.2.2.10-alpha. Minor bugfixes (ipv6): Allow non-SOCKSPorts to disable IPv4, IPv6, and PreferIPv4. Some rare configurations might break, but in this case you can disable NoIPv4Traffic and NoIPv6Traffic as needed. Fixes bug 33607; bugfix on 0.4.1.1-alpha. Patch by Neel Chauhan. Minor bugfixes (key generation): Do not require a valid torrc when using the `–keygen` argument to generate a signing key. This allows us to generate keys on systems or users which may not run Tor. Fixes bug 40235; bugfix on 0.2.7.2-alpha. Patch by Neel Chauhan. Minor bugfixes (logging, relay): Emit a warning if an Address is found to be internal and tor can’t use it. Fixes bug 40290; bugfix on 0.4.5.1-alpha. Minor bugfixes (metrics port): Fix a bug that made tor try to re-bind() on an already open MetricsPort every 60 seconds. Fixes bug 40370; bugfix on 0.4.5.1-alpha. Minor bugfixes (onion services, logging): Downgrade the severity of a few rendezvous circuit-related warnings from warning to info. Fixes bug 40207; bugfix on 0.3.2.1-alpha. Patch by Neel Chauhan. Minor bugfixes (relay): Reduce the compression level for data streaming from HIGH to LOW. This should reduce the CPU and memory burden for directory caches. Fixes bug 40301; bugfix on 0.3.5.1-alpha. Minor bugfixes (testing, BSD): Fix pattern-matching errors when patterns expand to invalid paths on BSD systems. Fixes bug 40318; bugfix on 0.4.5.1-alpha. Patch by Daniel Pinto. Code simplification and refactoring: Remove the orconn_ext_or_id_map structure and related functions. (Nothing outside of unit tests used them.) Closes ticket 33383. Patch by Neel Chauhan. Removed features: Remove unneeded code for parsing private keys in directory documents. This code was only used for client authentication in v2 onion services, which are now unsupported. Closes ticket 40374. As of this release, Tor no longer supports the old v2 onion services. They were deprecated last July for security, and support will be removed entirely later this year. We strongly encourage everybody to migrate to v3 onion services. For more information, see https://blog.torproject.org/v2-deprecation-timeline . Closes ticket 40266. (NOTE: We accidentally released an earlier version of the 0.4.6.1-alpha changelog without this entry. Sorry for the confusion!) Code simplification and refactoring (metrics, DoS): Move the DoS subsystem into the subsys manager, including its configuration options. Closes ticket 40261. Documentation (manual): Move the ServerTransport* options to the “SERVER OPTIONS” section. Closes issue 40331. Indicate that the HiddenServiceStatistics option also applies to bridges. Closes ticket 40346. Move the description of BridgeRecordUsageByCountry to the section “STATISTICS OPTIONS”. Closes ticket 40323. Removed features (relay): Because DirPorts are only used on authorities, relays no longer advertise them. Similarly, self-testing for DirPorts has been disabled, since an unreachable DirPort is no reason for a relay not to advertise itself. (Configuring a DirPort will still work, for now.) Closes ticket 40282.

Share This Information.

11 thoughts on “Updates from the Tor Project

  1. Great article! We are linking to this particularly great content on our site.

    Keep up the good writing.

  2. Way cool! Some very valid points! I appreciate you penning this post and
    the rest of the site is really good.

  3. Good post! We will be linking to this particularly great article on our website.
    Keep up the great writing.

  4. Good web site you have here.. It’s hard to find high quality writing like yours nowadays.
    I honestly appreciate people like you! Take care!!

  5. Admiring the commitment you put into your website and detailed information you provide.
    It’s awesome to come across a blog every once in a while that isn’t the same old rehashed information.
    Great read! I’ve bookmarked your site and I’m including your RSS feeds
    to my Google account.

  6. Woah! I’m really enjoying the template/theme of this site.
    It’s simple, yet effective. A lot of times it’s very difficult to get that “perfect balance” between user friendliness and visual appeal.
    I must say you’ve done a amazing job with this.
    In addition, the blog loads super quick for me on Internet explorer.

    Outstanding Blog!

Leave a Reply

Your email address will not be published. Required fields are marked *