Tor Project blog

Making new connections: from BridgeDB to Rdsys

2024-12-04T00:00:00Z

For over a decade, BridgeDB was the reluctant champion helping users bypass censorship and connect to the open web. Released more than 11 years ago as a prototype, the bridge distribution mechanism surpassed its original lifespan, honorably serving the Tor community. However, as censorship techniques evolved, BridgeDB became overburdened with the many updates necessary to adapt to these new challenges. Over time, this led to an accumulation of technical debt and outdated code which made further improvements and maintenance increasingly difficult. It became clear that to keep up with the dynamic nature of anti-censorship work, Tor needed a more robust, flexible and easier to maintain solution.

Enter Rdsys: the next-generation bridge distribution system. Developed from the ground up, it incorporates the learnings from over 15 years of anti-censorship work to overcome the limitations of its predecessor. In October 2024, Tor completed the migration to Rdsys, retiring Bridge DB. This transition ensures a more flexible, maintainable, and user-friendly approach to bridge distribution, strengthening Tor's ability to counter censorship and making the web more accessible to those who need it most.

Learning from the past

When Tor was first adopted by people circumventing censorship, it quickly became a target for censors. Blocking the public list of Tor relays was an easy way to cut off access. The solution? Bridges---relays that aren't listed publicly to make it harder for censors to block access to Tor. But as soon as bridges were introduced, two challenges emerged: how to disguise bridge traffic and how to distribute bridges securely without exposing them to censors.

While the former was addressed with different bridge types, BridgeDB addressed the latter: It needed to give legitimate users access to bridges while making it difficult for censors to obtain the entire list. So, it employed several distribution mechanisms, including web-based or email requests, and a Tor Browser API called MOAT. Users could either obtain bridge addresses through a website and by requesting them via email, or by solving captchas.

These approaches allowed for some degree of censorship protection, but they weren't foolproof. Censors could still attempt to scrape websites, flood the email system to collect bridges, or bypass them by leveraging human CAPTCHA-solving services.

As censorship tactics became more sophisticated, we kept adding to its original code base, resulting in an accumulation of technical debt. While it was a great solution at the time, BridgeDB grew increasingly difficult to maintain.

Pathing towards the future

Recognizing BridgeDB's limitations, we began developing Rdsys as a replacement four years ago. Unlike its predecessor, Rdsys is built as a modular system, dividing responsibilities into separate components--such as distribution logic and communication methods (e.g., email, Telegram)--that work together seamlessly. This architecture lets us experiment with new ideas and, eventually, adapt to emerging threats without overhauling the entire system:

Exploring new distribution channels

Rdsys enabled us to explore bridge distribution channels by leveraging platforms widely used in censored regions. For example, in response to increasing censorship in Russia, we successfully distributed bridges through Telegram. This approach takes advantage of account history, distinguishing between old and new accounts to ensure bridges are given to real users, not bots or censors creating accounts en masse.

Adding new tools

The modular design allows us to test and deploy new anti-censorship tools more rapidly to stay ahead of evolving tactics. Lox, for instance, is a bridge distribution mechanism that detects blocked bridges and uses a reputation-based approach rewarding users whose bridges remain unblocked.

Eliminating the hassle of captchas

For many, captchas are frustratingly inaccessible, presenting challenges for users with disabilities, those who rely on screen readers, or individuals using older devices with limited capabilities. For some users, solving captchas can even be impossible due to language barriers or overly complex visual puzzles, creating a bottleneck in their efforts to connect to the open web.

Beyond user experience, captchas have also become increasingly ineffective as a security measure. Censors have adapted to them, employing automated tools or other methods to bypass these obstacles. This renders captchas less of a deterrent for those aiming to restrict access while maintaining their burden on legitimate users.

By shifting away from captchas, Rdsys improves the accessibility and reliability of Tor bridges, ensuring that more users--particularly those in regions facing heavy censorship--can connect without unnecessary roadblocks.

What's next?

Looking ahead, the goal is not just to maintain access to the internet, but to expand it. This is where you, dear reader, come in!

Earlier this year, we launched Webtunnel, a new bridge type that blends itself into other web traffic. This was made possible in part through new systems like Rdsys, but mostly by the power of thousands of volunteers, contributors, and alpha testers who are committed to empowering internet users worldwide to reclaim their right to speak, browse, and search anonymously.

Now, we are calling on the Tor and Internet freedom community once again to help us scale Tor's anti-censorship efforts. If you've ever thought about contributing to Tor's development or of running a Tor bridge, today is the day. Together, we can ensure that everyone, everywhere has access to a free and open internet.

Arti 1.3.1 is released: onion services, RPC, relay development, and more

2024-12-03T00:00:00Z

Arti is our ongoing project to create a next-generation Tor client in Rust. Now we're announcing the latest release, Arti 1.3.1.

This release continues development on Arti Relay and the RPC subsystem, and adds the initial scaffolding for service-side proof-of-work support. It also contains a number of bugfixes, cleanups, as well as improvements to our CI infrastructure.

For full details on what we've done, and for information about many smaller and less visible changes as well, please see the CHANGELOG.

For more information on using Arti, see our top-level README, and the documentation for the arti binary.

Thanks to everybody who's contributed to this release, including Lionel Goffaux.

And as always, our deep thanks to Zcash Community Grants, the Bureau of Democracy, Human Rights and Labor, and our other sponsors for funding the development of Arti!

New Release: Tails 6.10

2024-11-28T00:00:00Z

Changes and updates

Update Tor Browser to 14.0.3.
Update Thunderbird from 115.16.0 to 128.4.3.

Fixed problems

Fix support for Trezor hardware wallets in Electrum. (#20138)
Fix an issue that prevented the Tails desktop to open with fewer memory. (#20631)
Disable saving telemetry data in Thunderbird. (#20661)

For more details, read our changelog.

Get Tails 6.10

To upgrade your Tails USB stick and keep your Persistent Storage

Automatic upgrades are available from Tails 6.0 or later to 6.10.
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 6.10 on a new USB stick

Follow our installation instructions:

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 6.10 directly:

Support and feedback

For support and feedback, visit the Support section on the Tails website.

Tor in Russia: A call for more WebTunnel bridges

2024-11-28T00:00:00Z

Recent reports from Tor users in Russia indicate an escalation in online censorship with the goal of blocking access to Tor and other circumvention tools. This new wave includes attempts to block Tor bridges and pluggable transports developed by the Tor Project, removal of circumvention apps from stores, and targeting popular hosting providers, shrinking the space for bypassing censorship. Despite these ongoing actions, Tor remains effective.

One alarming trend is the targeted blocking of popular hosting providers by Roscomnadzor. As many circumvention tools are using them, this action made some Tor bridges inaccessible to many users in Russia. As Roscomnadzor and internet service providers in Russia are increasing their blocking efforts, the need for more WebTunnel bridges has become urgent.

Why Webtunnel bridges?

Webtunnel is a new type of bridge that is particularly effective at flying under a censors's radar. Its design blends itself into other web traffic, allowing a user to hide in plain sight. And since its launch earlier this year, we've made sure to prioritize small download sizes for more convenient distribution and simplified the support of uTLS intergration further mimicing the characteristics of more widespread browsers. This makes Webtunnel safe for general users because it helps conceal the fact that a tool like Tor is being used.

We are calling on the Tor community and the Internet freedom community to help us scale up WebTunnel bridges. If you've ever thought about running a Tor bridge, now is the time. Our goal is to deploy 200 new WebTunnel bridges by the end of this December (2024) to open secure access for users in Russia.

How to run a Tor WebTunnel bridge

On the International Day Against Online Censorship in March, we published a blog post introducing WebTunnel: "Hiding in Plain Sight". Setting up a WebTunnel bridge requires some system administration skills, but we've streamlined the process to make it as straightforward as possible.

1. Using Docker: We offer a Docker image that simplifies deploying the Tor bridge and WebTunnel transport. Some additional configuration of your web server is required.

2. Ansible automation: A WebTunnel Ansible role, created by community member Jacobo Nájera, provides another way to set up a WebTunnel bridge quickly.

You can find the technical requirements in our WebTunnel guide. In short, you'll need:

A static IPv4 address (preferred)
A self-hosted website
A valid SSL/TLS certificate (e.g., Let's Encrypt)
Bandwidth usage: at least 1 TB/month, but more is recommendable.

Important: Avoid using free shared DNS services, as they are frequently blocked in Russia and other regions. Consult our community Good/Bad ISPs page for finding a provider for your WebTunnel bridge and avoiding popular hosting companies.

Bridge campaign rules for participation

The campaign starts today, November 28, 2024, and will run until March 10, 2025. As a token of our appreciation for your volunteer work, we're offering a Tor t-shirt to operators who run 5 or more WebTunnel bridges during this period. Please note: Only one t-shirt will be awarded per operator. See the technical requirements below to participate in the campaign.

Technical requirements for campaign

Operators must run one WebTunnel bridge per IPv4. It is acceptable to use multiple subdomains or distinct domains.
Include a valid email address as your contact information. Or we won't be able to confirm and validate your participation in the campaign.
Maintain your bridges running for at least 1 year.
Ensure your bridges have a solid uptime, operating close to 24/7. Reboots for updates are fine.
Your bridge must remain functional during the campaign period.
Do not host your bridges with Hetzner.

How to participate

After spinning up and verifying that your five WebTunnel bridges are working, confirm your participation by emailing frontdesk@torproject.org with the following template:

Subject: Participation in Bridge Campaign 2025
Body: Hi,
I'm signing up for the Tor Bridge Campaign. These are my bridges: 
    <Add here your bridge lines>
My t-shirt is (pick your size: https://gitlab.torproject.org/tpo/community/team/-/wikis/tshirts/tshirt-size-charts).

To validate your participation, please contact us using the same email address listed in your contactinfo. You can expect your reward to be shipped in Q2 2025.

Russian censors targeting pluggable transports

Tor-powered applications like Tor Browser include built-in censorship circumvention features, but censors in Russia are increasingly targeting these mechanisms. For example, user reports suggest that obfs4 connections are being blocked on some 4G mobile networks in Russia. Despite this, obfs4 remains the most widely used pluggable transport for Tor users in the country. Snowflake has also experienced partial blocks at certain providers and Tor's Anti-Censorship Team have been investigating.

Analyzing censorship tactics, developing fixes, and implementing new mitigations takes time and resources. In the meantime, Tor WebTunnel bridges serve as an urgent and immediate way to bypass censorship in Russia.

Tor-powered applications are critical for combating online censorship in heavily restricted regions. In a country where "the biggest banks were instructed to punish customers using credit cards to pay for VPN services", free and open source tools like Tor are some of the few remaining alternatives for keeping users connected.

Background: Tor blocked in Russia (2021)

In late 2021, the Russian government attempted to block Tor, as we detailed in our blog post. Despite the censors' best efforts, Russian users were able to circumvent the block using Tor bridges.

Upon launch of WebTunnel in early 2024, we only had 60 WebTunnel bridges. Today, the number has more than doubled to 143. However, we must improve our efforts to meet the rising demand and counter the evolving censorship landscape.

If you've ever considered running a Tor bridge, now is an excellent time to get started. Please help us spread the word as your help is urgently needed.

I want to help, but I am not tech-savvy

No problem, you can help us spread the word. Now, more so than ever, it is important to speak up. Share this in your social networks–online AND offline. If enough people read this, we can reach those who can support with the technical aspects of this ask.

You can also make a donation to the Tor Project. Right now, all donations are matched. That means when you donate $25, your donation will be matched by a generous donor, meaning Tor receives a total of $50. Every donation helps build our power in this fight.

Other resources

The freedom to browse with privacy

2024-11-27T00:00:00Z

Oftentimes we share stories about journalists, activists, whistleblowers, and people in authoritarian governments using Tor to speak truth to power without risking their lives. These are meaningful examples of the importance of Tor—but it’s important to remember that everyone, everywhere has the right to speak, browse and search with freedom and with privacy. That’s why today, we’re sharing a story from Signh*, an anonymous user who submitted their story to our call for Tor stories. People like Signh, who don't consider themselves tech-savvy, also deserve the right to browse freely.

*=pseudonym.

Who you support by supporting Tor: Signh, UK

Singh is a woman living in the UK who values her privacy and controls her online identity with Tor Browser. She's not a tech expert, but she understands the importance of protecting her personal data in today's digital world.

When Singh goes online, she mostly spends her time on social sites, and often gets caught doom scrolling about specific social and political issues that impact her life. Her activity leaves a trail of information that can be collected and used by her Internet Service Provider (ISP) and the websites she visits. Singh doesn't want companies knowing what she does online or where she's located, because she doesn't want that data being used to manipulate the content she's served.

That's where Tor Browser comes in. By using Tor Browser and its encryption and anonymity features, Singh can browse the web with confidence, knowing that her online activity is hidden from prying eyes. Her ISP can't see the websites she's visiting, and the websites she visits can't see her IP address. Tor Browser even protects her from fingerprinting techniques and cookies deployed by advertising technologies.

"I do not face any direct threats or risks regarding my use of the internet, and solely use Tor to avoid mass surveillance of my browsing history. Although my physical well being is not threatened by the mass surveillance I mentally feel much more at ease knowing that my browsing history is protected by using Tor."

With Tor, Singh has the power to decide who gets access to her browsing activity and IP address. She's not just a consumer; she's an active participant in her online experience.

Singh is one of millions of users who choose Tor Browser for her online privacy needs and believes in the right to browse with freedom.

How to contribute

The Tor Project is a nonprofit, but it’s also a free software organization and a community-focused project. We are building technology to protect people's privacy and combat mass surveillance regardless of who is in power. Together, we are working against a billion dollar industry based on data collection and mass surveillance.

We will continue to need your support to keep this fight going. Will you please consider giving to the Tor Project?

This year, all gifts made before December 31 will be matched up to $300,000.

fundraising

New Alpha Release: Tor Browser 14.5a1

2024-11-26T00:00:00Z

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

This version includes important security updates to Firefox.

We would like to thank the following community members for their contribution to this release:

NoisyCoil for several patches allowing us to create aarch64 Linux builds of our browsers,
cypherpunks1 for Tor Browser UI improvements on Android,
- tor-browser#43241
- tor-browser#43251

Send us your feedback

If you find a bug or have a suggestion for how we could improve this release, please let us know.

Full changelog

The full changelog since Tor Browser 14.0a9 is:

All Platforms
- Updated NoScript to 11.5.2
- Updated Tor to 0.4.8.13
- Bug tor-browser#41710: Refactor about:torconnects relation to TorConnectParent
- Bug tor-browser#42125: lock RFP part 2
- Bug tor-browser#43307: Rebase Tor Browser alpha onto 128.5.0esr
- Bug tor-browser#43313: Backport security fixes from Firefox 133
Windows + macOS + Linux
- Updated Firefox to 128.5.0esr
- Bug tor-browser#42186: Drop about:tbupdate
- Bug tor-browser#42597: Lox.generateInvite does not convert JSON object to string
- Bug tor-browser#42739: Fix localization in the profile error dialog
- Bug tor-browser#42802: Make use of :has CSS selector
- Bug tor-browser#43237: Tweak Tor circuit display panel for screen readers
- Bug tor-browser#43262: Onion keys dialog. "Remove" removes all keys, "Remove all" does nothing.
- Bug tor-browser#43263: Onion site keys: add some alerts for screen readers
- Bug tor-browser#43294: Replace Actor willDestroy with didDestroy
- Bug tor-browser#43314: Tidy up connection preferences for screen readers and keyboard users
macOS
- Bug MozBug 1768724#43165: Disable Microsoft SSO on macOS [tor-browser]
Linux
- Bug tor-browser#41786: Remove old fontconfig stuff at the next watershed update
- Bug tor-browser#41799: Make lack of fonts.conf less of a footgun
- Bug tor-browser-build#41298: Remove --detach parameter from .desktop files
- Bug tor-browser-build#41312: Remove comment in start-browser about --class and --name parameters
- Bug tor-browser-build#41313: Show waiting cursor while app opens
Android
- Updated GeckoView to 128.5.0esr
- Bug tor-browser#43232: Make the Android Meek transport easier to debug
- Bug tor-browser#43241: Improve hiding non-private tab features on Android
- Bug tor-browser#43251: Enable tab suggestions and autocomplete for private tabs on Android
Build System
- All Platforms
  - Updated Go to 1.22.9
  - Bug tor-browser#43272: Fix git fetch in translation CI
  - Bug tor-browser#43295: Update MR templates
  - Bug tor-browser-build#40996: Do not version the .nobackup files
  - Bug tor-browser-build#41279: Add @pierov and @ma1 as new signers
  - Bug tor-browser-build#41284: Update relprep.py script to not synchronise changelogs between channels
  - Bug tor-browser-build#41288: Use exec_noco option when using exec
  - Bug tor-browser-build#41289: Fix single-browser in relprep.py
  - Bug tor-browser-build#41300: Add bea, clairehurst, and jwilde to tb_builders
  - Bug tor-browser-build#41304: Add a browser commit tag+signing script
  - Bug tor-browser-build#41306: Container dependencies are sorted before resolving templates
  - Bug tor-browser-build#41307: Container dependencies are not filtered for duplicates
  - Bug tor-browser-build#41321: Update PieroV's expired keys
  - Bug rbm#40006: Add option to avoid doing a git checkout when using the exec template function
- Windows + macOS + Linux
  - Bug tor-browser-build#41286: Update the deploy update scripts to optinally take an override hash
- Linux
  - Bug tor-browser-build#41142: Complete the toolchain for linux-aarch64
  - Bug tor-browser-build#41266: Build the Tor and Mullvad Browsers for aarch64 Linux
  - Bug tor-browser-build#41282: Add SSL to our custom Python for MozBug 1924022

New Release: Tor Browser 14.0.3

2024-11-26T00:00:00Z

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

This version includes important security updates to Firefox.

Send us your feedback

If you find a bug or have a suggestion for how we could improve this release, please let us know.

Full changelog

The full changelog since Tor Browser 14.0.2 is:

All Platforms
- Bug tor-browser#43306: Rebase Tor Browser Stable onto 128.5.0esr
- Bug tor-browser#43313: Backport security fixes from Firefox 133
Windows + macOS + Linux
- Updated Firefox to 128.5.0esr
macOS
- Bug MozBug 1768724#43165: Disable Microsoft SSO on macOS [tor-browser]
Android
- Updated GeckoView to 128.5.0esr
Build System
- All Platforms
  - Updated Go to 1.22.9
  - Bug tor-browser-build#40996: Do not version the .nobackup files
  - Bug tor-browser-build#41284: Update relprep.py script to not synchronise changelogs between channels
  - Bug tor-browser-build#41300: Add bea, clairehurst, and jwilde to tb_builders

Memory quota tracking in Arti, for Onion Service DoS resistance

2024-11-19T00:00:00Z

Last week we released Arti 1.3.0, the latest version of our rewrite of Tor in Rust. One new feature in this release is memory quota tracking.

Tracking and restricting memory for queued data

The memory quota tracking feature allows you to restrict the amount of memory used by an Arti process. In particular, it allows you to limit the amount of memory that other people can cause your Arti to use.

This is particularly important when Arti is being used to provide an Onion Service (aka a Tor Hidden Service). Running an Onion Service means letting users from all over the network connect to your service (depending, to an extent, on your configuration settings). That means those users can cause your system to do work, and, generally, to store data in transit to and from your Onion Service. In 2014, Jansen et al discovered that this kind of data storage can even be used to help deanonymise your service.

We have now implemented the recommended countermeasure: Arti can track how much data is stored in its various queues. When the configured limit is reached, Arti starts shutting down connections, and discarding data, until the queued data is below the limit. We kill the connections with the oldest oustanding data. This minimises the impact on unrelated, innocent, traffic.

We'll also need this memory limit feature for Arti Relay, which is currently being developed.

Configuration

In Arti, the memory quota tracker is controlled by the [system.memory] configuration subsection in arti.toml. You can enable it by writing something like this:

[system]
memory.max = "1 GiB"

The feature is compiled in by default. Setting the limit for the first time requires an Arti restart. After that, adjusting (or removing) the limit can be done at runtime.

There is also a memory.low_water setting: When Arti needs to free memory because max is exceeded, it keeps tearing down connections until the usage is below low_water. This hysteresis helps stop the system oscillating. The defaualt value of low_water is 75% of max.

(Note that unlike C Tor's MaxMemInQueues setting, the current default in Arti is not to enable a memory limit. In Arti you must turn on the feature explicitly, by setting max. We hope to get more experience of how it works for users in practice, before we consider whether to enable a limit by default.)

Logging

After you've enabled memory quota tracking, you should see Arti print a log message like this:

2024-10-31T16:55:55Z  INFO tor_memquota::mtracker: memory quota tracking initialised max=1.00 GiB low_water=768 MiB

You can tell if memory reclaim has been triggered:

2024-10-31T17:22:19Z  INFO tor_memquota::mtracker::reclaim: memory tracking: 1.86 GiB > 1.00 GiB, reclamation started (target 768 MiB)
...
2024-10-31T17:22:20Z  INFO tor_memquota::mtracker::reclaim: memory tracking reclamation reached: 44.3 KiB (target 768 MiB): complete

Caution: very new code!

This is a very new feature. There is a lot of complexity behind the scenes, and by its nature it is difficult to do a full-scale integration test. It is quite possible that there are bugs! We'd like to hear your feedback, when you enable this feature.

You can report issues you discover in our gitlab (also available via an anonymous ticket reporting system). You can also contact us informally by email, or on irc: we're in #tor-dev on OFTC.

Thanks to our sponsors

Thanks to Zcash Community Grants for their funding, which enabled the development of this feature, and of course to our other sponsors for funding the development of Arti.

onion-services relays

New Release: Tor Browser 14.0.2

2024-11-13T00:00:00Z

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

This version fixes a tor crash bug on macOS when attempting to visit onion sites with PoW protections enabled (tor-browser#43245)

Send us your feedback

If you find a bug or have a suggestion for how we could improve this release, please let us know.

Full changelog

The full changelog since Tor Browser 14.0.1 is:

All Platforms
- Updated NoScript to 11.5.2
- Bug tor-browser#43257: NoScript-blocked content placeholders causing slow downs
Windows + macOS + Linux
- Bug tor-browser#32668: NoScript default whitelist re-appears on clicking NoScript Options / Reset
- Bug tor-browser#43258: NoScript Lifecycle error on extension updates
- Bug tor-browser#43262: Onion keys dialog. "Remove" removes all keys, "Remove all" does nothing.
macOS
- Bug tor-browser#43245: TB14 on macOS crashing when visiting some onionsites
Build System
- All Platforms
  - Updated Go to 1.22.9
- Windows + macOS + Linux
  - Bug tor-browser-build#41286: Update the deploy update scripts to optinally take an override hash

Defending the Tor network: Mitigating IP spoofing against Tor

2024-11-08T00:00:00Z

At the end of October, Tor directory authorities, relay operators, and even the Tor Project sysadmin team received multiple abuse complaints from their providers about port scanning. These complaints were traced back to a coordinated IP spoofing attack, where an attacker spoofed non-exit relays and other Tor-related IPs to trigger abuse reports aimed at disrupting the Tor Project and the Tor network.

Thanks to a joint effort from the Tor community, InterSecLab, and the support of Andrew Morris and the team at GreyNoise, the origin of these spoofed packets was identified and shut down on November 7th, 2024.

We want to reassure everyone that this incident had no effect on Tor users. While the attack had a limited impact on the Tor network - taking a few relays offline temporarily - it caused unnecessary stress and inconvenience for many relay operators who had to address these complaints. Although this attack targeted our community, IP spoofing attacks can happen with any online service.

There's still work ahead: we need to support relay operators in getting their accounts reinstated and assist providers in unblocking IPs for Tor directory authorities.

Hosting providers and abuse complaints

If you are a relay operator whose hosting provider is still blocking or has suspended your relay due to these complaints, here are steps you can take to resolve the issue:

Check Tor directory authorities reachability from your relay: If you suspect your provider has blocked Tor access -- i.e., because your relay dropped from the Tor consensus --, use OONI Probe and "Circumvention" test to check the reachability of Tor directory authorities. If the test shows that most directory authorities are reachable, your relay will successfully (re-)connect to the Tor network. If Tor directory authorities are still blocked, please contact your hosting provider support and share this blog post.
Reply to your hosting company: If you got contacted by your provider due to the abuse complaints, share this blog post to help them understand the incident and clarify that your Tor relay was targeted by a spoofing attack, and is NOT originating any suspicious traffic. You can adapt and use this template about abuse complaints.

Community strength and collaboration

This incident has demonstrated the resilience and collaborative spirit of the Tor relay operator community. Over the past days, we've seen many instances of good collaboration to defend the Tor network: analysis, investigation, and knowledge sharing. Relay operators worked together to troubleshoot issues, support each other over email and chat, and keep relays online.

We encourage relay operators to stay connected and informed through our official community channels and participate in our monthly relay operator meetups.

Thank you to every relay operator for your ongoing efforts to run relays, protect online privacy, and support the Tor Project! <3

Background: What happened?

On October 20, Tor directory authorities began receiving abuse complaints claiming that their servers were engaged in unauthorized port scans. In the Tor network, directory authorities play a critical role in maintaining the list of available relays.

This attack focused on non-exit relays, using spoofed SYN packets to make it appear that Tor relay IP addresses were the sources of these scans. This led to automated abuse complaints directed at data centers such as OVH, Hetzner, and other providers. The attacker's intent seems to have been to disrupt the Tor network and the Tor Project by getting these IPs on blocklists with these unfounded complaints.

Pierre Bourdon, a relay operator, shared insights into the attack in his post, "One weird trick to get the whole planet to send abuse complaints to your best friend(s)", which sheds light on how the attacker used spoofed IP packets to trigger automated abuse complaints across the network. A huge thank you to Pierre for his detailed analysis and for sharing his findings with the community!

While we received support from many individuals and organizations during this incident, we also experienced instances of unprofessional conduct, where a the refusal to investigate and lack of diligence inadvertently amplified the impact of this attack. Much of the reporting on this fake abuse attack comes from watchdogcyberdefense[.]com and we endorse the calls within the cybersecurity community to treat these reports with caution.

For a more detailed discussion, please refer to our public ticket on the issue and our mailing list.

While spoofing activity is not specific to Tor, it’s concerning that someone would choose to deliberately disrupt a service that is essential for people experiencing digital surveillance and internet censorship. Tor plays a critical role in supporting freedom of access and expression globally, and targeting it undermines these fundamental rights. We are grateful for the resilience and dedication of our relay operator community, whose collective efforts ensure the strength of Tor’s decentralized network.