Planet Tor

@pastly February 22, 2021 - 21:15 • 14 days ago
Enough about Hacker Factor's '0days'

Last summer Dr. Neal Krawetz AKA "Hacker Factor" made a series of posts on his blog about Tor "0days." This post is a summary of Tor Project's response to one of his posts. Neither this post nor Tor Project's tweet serve as a perfect point-by-point rebuttal of everything he claims in the post, nor all of his "0day" posts. The things that he says that are skipped over here are not automatically valid just because they are skipped. The theme of the responses hold for just about everything he ever says about Tor. As they say, it's easier to spread bullshit than it is to refute it.

Okay wait. Many of the things he says aren't bullshit. He has some valid points. He just can't express those points in a productive manner anymore. His Tor posts are riddled with phrases that instantly put Tor people on the defensive, so it's a masochistic exercise to review them again every time someone asks "hey, what's your thoughts on this HF guy's post from last year?"

The Tor Project tweet is a level headed response (that I helped write); again, this is just a summary of that response, and I'm taking the opportunity to vent while writing it. I will take no questions or comments, nor read emails about this post. I'm freely using inflammatory, emotionally charged language because-- unlike HF--I do not expect, or want, a conversation to come out of this. This is a crass cathartic exercise for me.

The title of the HF blog post this post deals with is "Tor 0day: Burning Bridges." You can find it with your favorite search engine; I'm not going to help drive traffic to his site.

Here we go. The actual content of this "short" post I'm writing for my own reference.

Use of the word 0day

HF knows exactly what he's doing when he uses the term "0day." He's not stupid. He knows what people immediately think when they here that term. He knows 0day sounds scary and gets people excited about a dangerous new discovery. He knows he'd get media attention.

He hides behind "well technically I'm correct because one of the little-used definitions of 0day includes things that aren't fixed and exist in the wild." You're technically and pointlessly correct, HF. And every time someone calls you out on this inflammatory word choice, you get the free rebuttal of "you're not even addressing the real issues! You just don't like my (perfectly valid!!!1!) word choice. You clearly have nothing." No. Fuck you. Use this excuse again if/when you see this, then fuck right off.

Scrollbar width

This is (and was) a publicly documented information leak. There are many ways the user's OS can be leaked (one of them is even on purpose!), and fixing just one of them without fixing many of the others is pointless.

People should report bugs like this so they can be documented and fixed in batches. People should not throw a hissy fit when the bug isn't fixed right away in order to validate their sense of self-importance.

Tor's TLS fingerprint

The way Tor uses TLS between relays and between a client and their relay is (and always has been) fingerprintable. This has been publicly known since 2007. Before HF, it was brought up in 2018 in a much more slanderous and make-a-name-for-yourself-at-the-cost-of-others tone (archive copy).

HF's proposed solution is the wrong one. Tor Project has decided on a better one: bridges with pluggable transports.

Obfs4 is identifiable

Perhaps surprisingly, this is known. It's also an important problem. It's being worked on at a pace slower than HF finds acceptable.

But HF presents variations on known attacks without evidence that they work at a large scale. Two possible issues: too much state to keep track of, or too many false positives such that the adversary is unwilling to deploy it. Luckily for HF, the bar for publishing "science" in a blog post is on the ground. He can say things confidentially and non-experts believe him. Shame on you, HF.

He further shows that he barely looked into this before putting pen to paper (or fingers to keyboard?) by

  • admitting to not knowing of any prior work (in response Tor Project points him to some),

  • citing a paper to support the claim that the Great Firewall can detect obfs4 when the paper say the opposite,

  • citing a blog post about obfs4 bridges being blocked in China, then ignoring that the issue discussed therein is about bridge distribution. Remember HF, in this section you were talking about fingerprintable network activity.

@blog March 4, 2021 - 00:08 • 5 days ago
New Release: Tor Browser 10.0.13 (Linux Only)
New Release: Tor Browser 10.0.13 (Linux Only) sysrqb March 03, 2021

Tor Browser 10.0.13 for Linux is now available from the Tor Browser download page and also from our distribution directory.

This version fixes instability on some Linux distributions.

The full changelog since Tor Browser 10.0.12 is:

  • Linux
    • Bug 40328: Fix instability after upgrading to glibc 2.33
@kushal March 3, 2021 - 04:34 • 6 days ago
Get a TLS certificate for your onion service

For a long time, I wanted to have a certificate for the onion address of my blog. Digicert was the only CA who was providing those certificates with an Extended Validation. Those are costly and suitable for an organization to get, but not for me personally, especially due to the cost.

TLS certificate working

A few days ago, on IRC, I found out that Harica is providing Domain validation for the onion sites for around €30 per year. I jumped in to get one. At the same time, ahf was also getting his certificate. He helped me with the configuration for nginx.

How to get your own certificate?

  • Make sure you have your site running as Tor v3 onion service
  • Create an account at
  • Goto server certificates on the left bar, and make a new request for your domain, provide the onion address as requested in the form.
  • It will give you the option to upload a CSR Certificate Signing Request. You can generate one by openssl req -newkey rsa:4096 -keyout -out csr.csr. For the common name, provide the same onion address.
  • After the click on the website, it will ask you to download a file and put it in your web root inside of .well-known/pki-validation/ directory. Make sure that you can access the file over Tor Browser.
  • When you click the final submission button, the system will take some time to verify the domain. After payment, you should be able to download the certificate with the full chain (the file ending with .p7b). There are 3 options on the webpage, so please remember to download the correct file :)
  • You will have to convert it into PEM format, I used the command ahf showed me: openssl pkcs7 -inform pem -in -print_certs -out -outform pem

Setting up nginx

This part will be the same as any other standard nginx configuration. The following is what I use. Please uncomment the Strict-Transport-Security header line only after you are sure everything is working fine.

server {
	listen unix:/var/run/tor-hs-kushal.sock;

    server_name kushal76uaid62oup5774umh654scnu5dwzh4u2534qxhcbi4wbab3ad.onion;
    access_log /var/log/nginx/kushal_onion-access.log;

    location / {
	return 301 https://$host$request_uri;


server {
    listen unix:/var/run/tor-hs-kushal-https.sock ssl http2;

    server_name kushal76uaid62oup5774umh654scnu5dwzh4u2534qxhcbi4wbab3ad.onion;
    access_log /var/log/nginx/kushal_onion-access.log;

    ssl_certificate /etc/pki/;
	ssl_certificate_key /etc/pki/;

    #add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
	add_header X-Frame-Options DENY;
	add_header X-Content-Type-Options nosniff;
    # Turn on OCSP stapling as recommended at
    # requires nginx version >= 1.3.7
    ssl_stapling on;
    ssl_stapling_verify on;

    # modern configuration. tweak to your needs.
    ssl_protocols TLSv1.2;
    ssl_prefer_server_ciphers on;

	index index.html;
	root /var/www/;

	location / {
		try_files $uri $uri/ =404;

I also have the following configuration in the /etc/tor/torrc file to use the unix socket files.

HiddenServiceDir /var/lib/tor/hs-kushal/
HiddenServiceVersion 3
HiddenServicePort 80 unix:/var/run/tor-hs-kushal-me.sock
HiddenServicePort 443 unix:/var/run/tor-hs-kushal-https.sock

In case you want to know more about why do you need the certificate for your onion address, the Tor Project has a very nice explanation.

@blog February 26, 2021 - 01:10 • 11 days ago
New Release: OnionShare 2.3
New Release: OnionShare 2.3 micah February 25, 2021

This post was originally published on Micah Lee's blog.

After a ridiculously long sixteen months (or roughly ten years in pandemic time) I'm excited to announce that OnionShare 2.3 is out! Download it from

This version includes loads of new and exciting features which you can read about in much more detail on the brand new OnionShare documentation website, For now though I'm just going to go over the major ones: tabs, anonymous chat, and better command line support.

Doing all the things at once

In the olden days, OnionShare only did one thing: let you securely and anonymously share files over the Tor network. With time we added new features. You could use it as an anonymous dropbox, and then later to host an onion site.

But what if you wanted to, for example, run your own anonymous dropbox as well as share files with someone? If your OnionShare was busy running a service, you couldn't run a second service without stopping the first service. This is all fixed now thanks to tabs.

onionshare's new layout

Now when you open OnionShare you are presented with a blank tab that lets you choose between sharing files, receiving files, hosting a website, or chatting anonymous. You can have as many tabs open as you want at a time, and you can easily save tabs (that's what the purple thumbtack in the tab bar means) so that if you quit OnionShare and open it again later, these services can start back up with the same OnionShare addresses.

So with OnionShare 2.3 you can host a few websites, have your own personal anonymous dropbox, and securely send files to people whenever you want, all at the same time. Under the hood, the addition of tabs also makes OnionShare connect to the Tor network faster, especially if you're using a bridge.

Secure, anonymous, ephemeral chat rooms that don't log anything

Another major new feature is chat. You start a chat service, it gives you an OnionShare address, and then you send this address to everyone who is invited to the chat room (using an encrypted messaging app like Signal, for example). Then everyone loads this address in a Tor Browser, makes up a name to go by, and can have a completely private conversation.

onionshare chat

If you're already using an encrypted messaging app, what’s the point of an OnionShare chat room? It leaves fewer traces.

If, for example, you send a message to a Signal group, a copy of your message ends up on each device (the devices, and computers if they set up Signal Desktop of each member of the group). Even if disappearing messages is turned on it’s hard to confirm all copies of the messages are actually deleted from all devices, and from any other places (like notifications databases) they may have been saved to. OnionShare chat rooms don’t store any messages anywhere, so the problem is reduced to a minimum.

OnionShare chat rooms can also be useful for people wanting to chat anonymously and securely with someone without needing to create any accounts. For example, a whistleblower can send an OnionShare address to a journalist using a disposable e-mail address, and then wait for the journalist to join the chat room, all without compromising their anonymity.

Because OnionShare relies on Tor onion services, connections between the Tor Browser and OnionShare are all end-to-end encrypted (E2EE). When someone posts a message to an OnionShare chat room, they send it to the server through their E2EE onion connection. The OnionShare server then forwards the message to all other members of the chat room through the other members' E2EE onion connections, using WebSockets. OnionShare doesn’t implement any chat encryption on its own. It relies on the Tor onion service’s encryption instead.

Huge thanks to Saptak Sengupta for developing the anonymous chat feature (doing the bulk of the work in like a single day (!), in the midst of a hacker con in Goa, India last March).

OnionShare from the command line

onionshare command line

OnionShare 2.3 finally de-couples the command line and the graphical versions. You can install onionshare-cli on any platform, including headless Linux servers, using pip:

pip3 install --user onionshare-cli

You also need to have tor installed to use it from your package manager, or Homebrew if you're using macOS.

It's simple to use. For example, here's how you start a chat server:

onionshare command line

I hope you enjoy the new version of OnionShare!

Note February 21, 2021: OnionShare 2.3 for Linux will be available in Flathub after this pull request is reviewed and merged, so hang tight. In the meantime, it's already available in Snapcraft (though it logs analytics), or you can install the .flatpak file directly from

Update February 22, 2022: Version 2.3 had a bug where chat was broken :( but we just released version 2.3.1 which fixes it! :).

Update February 23, 2020: The Flatpak package is live! Linux users get it from Flathub.


If you'd like to leave a comment, you can do so on Micah Lee's original blog post.



@blog February 24, 2021 - 18:54 • 12 days ago
Learning more about our users
Learning more about our users duncan February 24, 2021

At the Tor Project we practice user-centered design. This means we put our users at the heart of our development process, making a conscious effort to understand the contexts in which people use our tools and paying particular attention to the bumps they encounter along the way.

Many digital product companies rely heavily on data gathered from invasive tracking scripts to better understand their users’ behavior, further fueling the surveillance economy. However that’s not how we do things at Tor – instead, we aim to conduct research that respects the basic principles of privacy and consent.

Prior to 2020, Tor Project contributors and local volunteers traveled to meet our users in their own communities across the world, with a special emphasis on the global south. Now, due to the challenges of the COVID-19 pandemic, much of this research has moved online – and we’re hoping to augment our qualitative interviews and training sessions with larger-scale quantitative research in a way that continues to respect our users’ privacy.

The Tor Project team and friends of Tor in Stockholm, 2019

Tor Browser User Survey

At our Stockholm All Hands meeting in July 2019 we circulated a pilot paper survey among attendees (as in the kind you fill out with a pen and drop into a box) to learn more about their experience using one of our tools in particular: Tor Browser. Although the sample size was intentionally small and heavily skewed towards internal contributors and friends of Tor, it nonetheless gave us a clear indication of the pain points (i.e. frustrations) many of our users encounter while browsing.

Now we’re ready to open up this research to all Tor Browser users in the form of the Tor Browser User Survey – and would like to invite you to give us your feedback:

Launch the Tor Browser User Survey

This survey is also available as a .onion, which can be opened directly in Tor Browser, providing a greater level of security and privacy for survey participants:

Open the Tor Browser survey as a .onion

Snowflake Client User Survey

For those who aren’t familiar, Snowflake is an in-development Pluggable Transport that’s designed to defeat internet censorship, available for testing in Tor Browser Alpha. You can find out more about how to use Snowflake to bypass censorship and how to install the Snowflake extension to help users in censored networks on our Support portal.

We’ve been steadily increasing the number of users testing Snowflake over the past 6 months as we continue to scale up for a future stable release, and alongside the Tor Browser User Survey we’d like to invite Snowflake users to feed back on their browsing experience and connection quality while using it as a client:

Launch the Snowflake Client User Survey

As with the Tor Browser User Survey, the Snowflake Client User Survey is also available as a .onion to help safeguard your privacy while responding:

Open the Snowflake survey as a .onion

Please note: for your personal safety we recommend high-risk individuals do not include any personally identifiable information. As such, certain questions have been marked as optional or include the option to respond “Prefer not to disclose” where appropriate.

Get involved in open user research for Tor

If you’d like to take a step further and volunteer to run an online research session in your own community we host an open call for user research at our monthly User Experience (UX) Team meetings. To get advance notice of the next UX Team meeting subscribe to the UX mailing list and we’ll send you a reminder a few days before it happens. If you want to be extra-prepared, we recommend visiting the Tor Project’s Community portal to get up to speed with our previous work and research methods too.

@blog February 24, 2021 - 12:26 • 13 days ago
New Release: Tor Browser 10.5a11
New Release: Tor Browser 10.5a11 gk February 24, 2021

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

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

This release updates Firefox to 78.8.0esr for desktop and Firefox for Android to 86.1.0. Additionally, we update Tor to and OpenSSL to 1.1.1j. This release includes important security updates to Firefox for Desktop, and similar important security updates to Firefox for Android.

Note: Tor Browser 10.5 does not support CentOS 6.

The full changelog since Tor Browser 10.5a8 (Linux, MacOS), 10.5a9 (Android), and 10.5a10 (Windows) is:

  • All Platforms
    • Update NoScript to 11.2.2
    • Update OpenSSL to 1.1.1j
    • Update Tor to
  • Windows + OS X + Linux
    • Update Firefox to 78.8.0esr
    • Bug 40029: Create survey banner on about:tor for snowflake
  • OS X + Linux
    • Update HTTPS Everywhere to 2021.1.27
    • Bug 40212: Bump version of snowflake and webrtc
  • Android
    • Update Firefox to 86.1.0
    • Bug 40144: Hide Download Manager
    • Bug 40148: Create survey banner on about:tor for Snowflake
    • Bug 40344: Set
  • Build System
    • Linux
@blog February 23, 2021 - 20:09 • 13 days ago
New Release: Tor Browser 10.0.12
New Release: Tor Browser 10.0.12 sysrqb February 23, 2021

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

This version updates Desktop Firefox to 78.8.0esr and Android Firefox to 86.1.0. In addition, Tor Browser 10.0.12 updates NoScript to 11.2.2, Openssl to 1.1.1j, and Tor to This version includes important security updates to Firefox for Desktop, and similar important security updates to Firefox for Android.

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

  • All Platforms
    • Update NoScript to 11.2.2
    • Update Openssl to 1.1.1j
    • Update Tor to
  • Windows + OS X + Linux
    • Update Firefox to 78.8.0esr
    • Bug 40026: Create survey banner on about:tor for desktop
    • Bug 40287: Switch DDG search from POST to GET
  • Android
    • Update Firefox to 86.1.0
    • Bug 40138: Create survey banner on about:tor for Android
    • Bug 40144: Hide Download Manager
    • Bug 40171: Make WebRequest and GeckoWebExecutor First-Party aware
    • Bug 40188: Build and ship snowflake only if it is enabled
    • Bug 40309: Avoid using regional OS locales
    • Bug 40344: Set
  • Build System
    • Android
      • Bug 40214: Update AMO Collection URL
      • Bug 40217: Update components for switch to mozilla86-based Fenix
@pastly February 12, 2021 - 14:06 • 25 days ago
Debunking 'OSINT Analysis of the TOR Foundation' and a few words about Tor's directory authorities

The following post was not written by me. It was written by Julien Voisin and posted on his blog in October 2018. I am sharing it here, unedited except as noted below, according to the CC BY-SA license of the post.

Edits made:

  • Add table of contents.
  • Change local links to point to my copies of the paper and its figures, not Julien Voisin's copies.

The paper it talks about is old news at this point (from 2018), but I see someone stumble upon it every few months ... instances that are just spread out enough I can never remember where this amazing post is on the web. Now I can't lose it.

Title: Debunking "OSINT Analysis of the TOR Foundation" and a few words about Tor's directory authorities
Date: 2018-10-04 15:00

I have spent years on Tails' IRC channel answering questions from various users, amassing a pile of personal notes about the internals of both Tor and Tails in the process.

A friend of mine linked me an "interesting" paper (local mirror) entitled OSINT Analysis of the TOR Foundation, and was wondering how much trust to put in it. I read it, and decided that it was so hilariously bad that it deserved a blogpost. It's also a nice opportunity to explain a few things about the directory authorities (dirauth).

The post is in two parts: first, a rough explanation about what the dirauth are and how resilient is the tor network with regard to them, then a complete review of the paper.

Tor and the dirauth

The Tor network is mainly composed of relays run by volunteers, with various attributes: exit, fast, guard, hsdir, running, stable, valid, badexit, v2dir, … but also authority.

Tor 0.0.2, released in 2004, introduced Directory Authorities, servers that served (duh.) cryptographically signed directory documents, containing a list of all relays along with their associated metadata (capacity, version, uptime, …) and status.

But the first version of the directory protocol didn't prevent a lying authority from providing a distorted view to some clients. This is why the second iteration implement cryptographic signature, to allow the client to only trust the directory documents signed by strictly more than half of all the dirauth.

The third version (which happens to be the current one) provides support for offline storing of critical cryptographic material for the dirauth, so that keys don't have to be stored in plain-text on the machines anymore. Furthermore, it introduced a nicely constructed consensus for the dirauth, instead of asking the client to aggregate all the separate data, to fight partitioning attacks.

It's possible to take a look at what the consensus looks like here.

How are new relays registered?

When a new relay comes online, it uploads its relay descriptor to a dirauth, to register itself with the tor network. Each dirauth is taking its view of the network and every hour gossip their 'vote' of the view of the network (which is essentially all the relay descriptors that they are aware of, and the bwauth measurement results) with the other directory authorities, and that is all merged into one 'consensus document' that is the global view of the network for a certain duration. That consensus document is fed to the fall-back authorities, who are the frontlines to clients coming online and needing to load the current state of the network.

Who controls the dirauth?

There are currently 10 relays with this flag:

Additionally, there is a bridge authority, that isn't a v3 directory one, listed here only for completeness' sake:

All of them are either in North-america or in Europe. I'm not in the business of doxing people, but it's pretty easy to find the social graph and nationality of all the admin in the list, their relationship to the Tor project, and even to have a beer with some of them :)

What happens to the network if the dirauth goes down?

If the authorities were all shut down, clients would still be able to download the list of relays: your client doesn't actually get the relay documents directly from the authorities, but from caches from Tor nodes with the V2dir flag. Your tor client has as well a local cache anyway.

As for compromised directory authorities, starting from the version 2 of the directory protocol, on top of downloading the actual relay documents, your client is also getting hashes of the relay documents signed by other authorities: relay documents will only be trusted if they are signed by at least half of the authorities. If one or two or three authorities were to be compromised, they won't be force clients to accept a distorted versions of the consensus.

Can't we replace the authorities with something more distributed?

It's a non-trivial problem.

Attacks on the dirauth

I discussed a bit with nextgens and others about the dirauth, and it's actually not that trivial to influence them. The goto way would be to simply pop them, but I do trust their respective maintainer to have deployed a bunch of fancy mitigations and monitoring.

An other way would be to influence them, by taking control of the pipes of the majority of the dirauth to influence their measurements. Fortunately, the dirauth aren't really doing measurements on their own: bandwidth authorities (bwauth) are, and those are transmitting their calculations to the dirauth they have a pre-established relationship with. Some bandwidth authorities are being run by dirauths, but most of them are not being run on the dirauth machine itself, but are 'hidden' elsewhere on the network

The paper

Author and context

The paper was written by Maxence Delong, Eric Filiol, Clément Coddet, Olivier Fatou and Clément Suhard, from the ESIEA, in Laval, more specifically, from the Operational Cryptology and Virology Laboratory (C + V)O. At this time, everyone but Eric Filiol was a student

Eric Filiol is known for pretending to have broken AES in 2002 (he didn't), and in 2003 (he still didn't) and Tor in 2011 (he didn't either), and for being the architect and designer of DAVFI, a French "new generation anti-malware solution", known for a being a phenomenal (and extraordinary expensive) source of fun.

The paper was presented at the 13th International Conference on Cyber Warfare and Security (ICCWS 2018), and apparently underwent a "double-blind peer review process". The conference is organised by Academic Conferences and Publishing International Limited, organizers of a bunch of conferences.

The blog of the Operational Cryptology and Virology Laboratory (C + V)O published a blogpost entitled "OSINT on the TOR Foundation (Update)", by Eric Filiol, containing two exaggerations (amongst, as usual, various typos):

As we shown on our paper “OSINT Analysis of the TORFoundation”, we worked on the funds and proved that the US government is deeply involve with arpproximatly 85% of the funds in 2015.

The paper states the following:

As we can see, at least 58.20% of the total funds are coming from different departments of the US government. The status of RFA (Radio Free Asia) Contract is unclear and there are persistent allegations and testimonies (Prados, 2017; Levine, 2015) or even suggestions that it could be strongly connected to the CIA more than expected (Levine, 2015). Would this suspicion be true, the rate of funds from US government-related entities would grow up to 85.24%.

There is a difference between a suspicion, and the blogpost's affirmation, especially when it changes a number from 58.20% to 85.24%.

Secondly, we had some reasons to believe that the US government has strong links with The TOR Project Inc. via Roger Dingledine who made an internship in NSA and with some presentations in front of high authorities like the White House and the FBI.

I don't think that doing an Summer internship at the NSA qualifies as a "strong link". About the presentations, it's well known that R. Dingledine does a lot of them to law enforcement entities, to improve their view on the network, and more broadly the Tor ecosystem. A lot of his bio for various conferences are ending with this:

In addition to all the hats he wears for Tor, Roger organizes academic conferences on anonymity, speaks at a wide variety of industry and hacker conferences, and also does tutorials on anonymity for national and foreign law enforcement.

I don't think that this could be viewed as a credible connection to the US government.

Form and sources

It's worth noting that while all the figures used in the paper are unreadable, it's possible to extract them with pdfimages (or to check the sources) to see that they are in pretty high-resolution, and actually readable: Figure 1., Figure 2., Figure 3. and Figure 4..

The figure 3. doesn't come with any legend with regard to the used currency, but since its point is to show a ratio, it doesn't matter much.

Despite a second revision to improve the English and remove the typos, the paper is still full of typos, frenchisms, and oddly worded sentences. Amusingly, this is the diff between the second and the third (and final at this time) revision of the paper:

-\author{Maxence Delong$^{1}$, Eric Filiol$^{2}$, Clément Coddet$^{3}$, Olivier Fatou$^{4}$, Clément Suhard$^{5}$}% <-this % stops a space
+\author{Maxence Delong, Eric Filiol\thanks{Contact author: \url{}}, Clément Coddet, Olivier Fatou, Clément Suhard\\
+        ESIEA Laval, Operational Cryptology and Virology Laboratory $(C + V)^O$ \\ 38 rue des Drs Calmette et Gu\'erin 53000 Laval France}% <-this % stops a space

E. Filiol is the only one with an email address, and apparently the main author of the paper.

About the sources of the papers, almost a third (3/10) of them are from "Filiol et al."


The paper is making several baseless/inflated insinuations, also known as loaded questions, a classic fallacy technique.

Officially, this foundation has no link with US government (any other one) and is independent (Dingledine, 2017). There is a growing feeling that this may not be the case.

Recurrent questions arise that put this apparent independency into question: what if the US government was behind the TOR network and somehow controls it?

In fact, the TOR project is an implementation of a concept born in the US Naval Research Laboratory (Goldschlag et al., 1996; Syverson et al., 1997). Paul Syverson is the designer of the routing protocol and was part of the original development team of the TOR network. Hence the TOR infancy was clearly linked with the US government and still is.

Furthermore, Roger Dingledine spent a summer in internship in the NSA, so we can suppose that he has kept a few contacts in there

The owner is Roger Dingledine, one of the three creators of the TOR Project (and a former NSA employee).

Roger only did a Summer internship at the NSA, I wouldn't call him a "former NSA employee".

Sloppy research

The title of the paper is "OSINT Analysis of the TOR Foundation", and refers the "TOR foundation" or "foundation" at least 40 times in the paper, as well to a company and a firm, but there are no such things: The Tor Project, Inc. is a "Massachusetts-based 501(c)(3) research-education nonprofit organization". Moreover, the proper capitalization is Tor to refer to the project, and tor to refer to the client or the network.

The authors didn't do a proper job to find the current Tor specification:

In this part, we will talk about the directory authorities (see tor-0_2_1_4_alpha/doc/spec/dir-spec.txt for details).

The canonical link for it is The linked Tor was released in 2008-08-04, ten years before the publication of the paper.

The article doesn't understand the concept of pseudonymity:

It is a real problem for the network: do users can trust people they do not know? Where do these people come from? What is their background?

The Tails developers are all pseudonymous, it doesn't prevent the project from being used and trusted by thousands of people around the world, and endorsed by many.

Some famous projects have (or used to have) pseudonymous contributors: Bitcoin, Truecrypt, DOTA, … most of Wikipedia's contributors are too, and all of those projects are used and trusted.

I'm way more comfortable knowing that the directory authorities aren't all managed by Tor employees. Moreover, only a single authority (two when the paper was written) is managed by well known collectives/pseudonymous people.

All of them are well established entities, known and trusted by many. Saying that they are unknown and with a mysterious background is a pretty bold statement. Moreover, "where do these people come from" is a pretty irrelevant question.

Peter Palfrader was the owner of tor26 (the first directory authority which does not belong to Roger Dingledine). Released in the version tor- in October 2004, the directory authority is not working anymore.

This is a plain lie: tor26 is working continuously since at least 5 years.

If a few people need to be on the Core People page, it will be the founder of the TOR Foundation and the people running a directory authority. With this disappearance, the customers have less information about the people who actually handle the network.

Although Paul Syverson worked with Roger Dingledine and Nick Mathewson, he never was part of the Tor Project Inc. He's still doing research on Tor, anonymity and onion-routing though.

On a side note, using the term "customers" instead of "users" is interesting: Tor has nothing to sell, everyone can use the tor network for free.

There are at least 25 research papers coming from Paul Syverson for the TOR network. The last example in date was the 18th of September 2017 for the version tor- which was imple- mented by following a paper wrote by Paul Syverson and his team from the US NRL only.

Saying that there are "at least 25" papers without naming a single one of them is not a correct way to provide sources. Referring to a paper by its date of publication isn't either. The paper in question being likely Never Been KIST: Tor’s Congestion Management Blossoms with Kernel-Informed Socket Transport by Rob Jansen, John Geddes, Chris Wacek, Micah Sherr and Paul Syverson, followed by Tor's Been KIST: A Case Study of Transitioning Tor Research to Practice by Rob Jansen and Matthew Traudt.

The first paper wasn't written by "Paul Syverson and his team form the US NRL only": only Syverson and Jansen are from the U.S. Naval Research Laboratory; Geddes is from the University of Minnesota while Wacek and Sherr are from the Georgetown University.

Officially, TOR is not developed anymore by the US government but a major part of changes was designed and developed by Paul Syverson through the US NRL and some people have work closely for the US government (not only among founders).

This is a bold statement without any kind of proof, but because the Tor Project has a lot of code split in different projects, a simple git shortlog on tor's source code shows that this is completely wrong:

$ git show | grep '^Date'
Date:   Fri Sep 21 09:54:22 2018 -0400
$ git shortlog -s | sort -nr | head -n 25
 16963  Nick Mathewson
  6245  Roger Dingledine
   715  Peter Palfrader
   678  David Goulet
   546  George Kadianakis
   502  Sebastian Hahn
   492  teor
   417  Andrea Shepard
   362  Karsten Loesing
   322  Mike Perry
   300  Andrew Lewman
   268  teor (Tim Wilson-Brown)
   234  Robert Ransom
   221  rl1987
   150  Alexander Færøy
   145  Isis Lovecruft
   137  cypherpunks
   111  Linus Nordberg
    87  Steven Murdoch
    83  Taylor Yu
    77  Yawning Angel
    73  Cristian Toader
    47  Neel Chauhan
    47  Jacob Appelbaum
    46  Paul Syverson

In this list, only Paul Syverson has (public) affiliations with the US government.

We note that the Core People page is not containing infor- mation about a few important people in the TOR Foundation. This page is not sufficient to have an idea of who are the true leaders of the foundation. We have explained who are the leaders of the network (directory authorities) but not those of the foundation.

The board of director of the Tor project is public, and apparently, the authors of the paper forgot to check the Past Contributors, because it documents the role of every single significant past contributor to the Tor Project.

Some contractors were hired, Pearl Crescent for example (a developer), and were “hidden” by the foundation. The TOR foundation asks indirectly a blind trust on the source code (due to the huge amount of line) and they give the development to people we do not even know.

Pearl Crescent isn't a developer at all, it's a company, referred as Pearl Crescent LLC. in the report. Its activity was thoroughly documented on the tor-reports mailing list, and their patches publicly (like any other ones) reviewed.

We discover a few names that are not on the Core People page. Rob Thomas, Meredith Dunn, Andrew Lewman, Mike Perry and Andrea Shepard are still unknown.

Rob Thomas is the founder and CEO of Team Cymru.

Meredith Hoban Dunn is an accountant, advisor, and banker. She's the one that signed the financial audits reports, and is designated as the treasurer of The Tor Project, Inc in it.

Andrew Lewman, as indicated on the past contributors, is the former Executive Director. He managed the business operations of The Tor Project, Inc. Played roles of finance, advocacy, project management, strategy, press, law enforcement liaison, and domestic violence advocacy. He was (likely, I don't have much details) fired, and is now running a shady company that does darknet-related-intelligence-magic-stuff.

A quick glance to the Which PGP keys sign which packages page shows that Mike Perry is/used to be the Tor Browser's lead developer. The financial report indicates that he's a developer, and a quick glance to the commits history of tor quickly confirms this. He was my mentor during my Google Summer of Code, in 2011, when I wrote the first iteration of MAT. I'm not surprised that he doesn't want to appear on the "Core People" page: he's a very private person.

Andrea Shepard was a Tor developer, as shown by a quick git shortlog, and as indicated in the 2015's financial report. She was brought to the fore during the Jacob Appelbaum events.

The TOR Foundation is regularly claiming that the US government is not funding anymore the TOR Project (Din- gledine, 2017)

This is a plain lie: the document to source this affirmation is Roger's DEFCON 25's presentation, which actually shows that Dingledine actually debunked the following "myths" during his talk, along with several other ones listed in the paper:

  • “I heard the Navy wrote Tor originally, so how can I trust it?”
  • “I heard the NSA runs half the relays.”
  • “I heard Tor gets most of its money from the US government.”
  • “I heard 80% of Tor is bad people.”

The table 2. is right (notwithstanding the typos), but since it's mostly copy/pasted data from the financial report, it's not surprising.

We will not develop most of the technical aspects that could suggest or confirm that somehow the TOR network has been designed or is managed in such a way that a few “facilities” are possible and would enable to take control over it. As a consequence, taking the control of a reduced number of TOR relays (from 450 to 1400 only) would enable to reduce the TOR traffic of at least 50 % and would greatly ease correlation attacks (about 35 % of the traffic) or eavesdropping (about 10 % of the traffic).

Yet an other loaded question, and references to other papers from Filiol; I might publish my lecture notes about them at some point in the future too.

As far as the relay bridges management is concerned, it has been possible to extract slightly more than 2,500 such bridges thus compromising the alleged ability to bypass censorship.

This has been debunked several times.

During our study, in September 2017, we were contacted by a user of a custom TOR library. This library is the “node- Tor” written in JavaScript and allows the user to create and run a node or connect to the TOR network. Further exchanges with this person have shown a lot of inconsistency and irregularities.

The person here is actually Aymeric Vitte. I sent him an email, and he felt that Filiol's paper deserved a public response on tor talk. I do recommend its reading ;)

At first, we talk about the way that his node was added to the network. For this custom library, the user asked the TOR foundation to add a node with this library and after an exchange of a few mails the node was accepted and run. The library is very different from the original source code. To compare very simply those two codes, we just compared the number of code lines. We know that the number of code lines does not really reflect the effect of the code but between the original source code (several hundreds of thousands code lines) and the library (only fifteen hundred code lines), we can assure that it is very likely that a number of options or securities are missing.

They are comparing the number of lines in a minimal javascript (a high-level language) implementation of Tor, and the official full-blown implementation, written in C (a kind of low-level language): this comparison metric doesn't make any sense.

Moreover, implying that Tor-node is only 1500 lines of code is a ludicrous claim, given how much it does.

Anyone can add a node to the network, there is no such thing like "ask the TOR foundation (sic.)" to add one.

It is not the designer of this code who is responsible but rather the TOR foundation for accepting a node on the network with this kind of library. The first problem is that no one is warned that this node is special and is not running the official source code. This node owned by a user is not controlled by the TOR foundation. So if the user is malicious, he could modify his node and make every change he wants. If a government wants to include this kind of node to log the traffic and gather it, he can do it very simply and without triggering any alert.

Having several implementations of tor relay running on the network is a actually a great idea: this improves the security of the network (a bug found in an implementation might not be present in an other one), and helps to find bugs or specification issues, which is a great thing in my opinion.

For example, CVE-2018–17144 was likely found due to implementation disparities between different bitcoin clients.

The tor network doesn't put much trust into relays themselves: any entity is free to run whatever nodes it wants, this is how the network is designed to work. Although, abuses might happen, and this is why there as several documented countermeasures and monitoring projects: Volunteers are running continuous checks to measure the integrity and trustworthiness of exit-nodes: are they tampering with the traffic or running active analysis? Malicious nodes are flagged and blacklisted from the network on a continuous basis.

If the security of the network is ensured by the fact that all the nodes run the same source code, with the same security level, the same options and so on. . . this fact proves that the TOR network is not so secure.

It's absolutely not the case, as explained in the previous paragraph. It seems that Filiol et al. have no idea about the threat model nor implementation of the Tor network at all.

We have discovered that with only few exchanges with the TOR foundation, we can add a custom node (possibly malicious). As for every node, no systematic control is possible by the TOR foundation, once accepted within in the network, we can do what we want with this node, log the traffic, insert biases in the creation of circuits etc. . . In summary, we think that the TOR project should not accept custom codes in order to respect the uniformity of the network that ensures “security”.

As previously explained, the only way to add a node to the network is to register it to the authorities, there is no such thing as "few exchanges with the TOR foundation", since the network isn't managed by it, nor by anyone, expect the authorities.

The very fact that anyone can run a relay ensures the security and anonymity of the network: imagine if a single entity would approve or reject who could join tor…

As far as confidence is concerned, nobody (except state organization) has the courage/time to read the source code and no one is paying attention to the designer of the changes on the TOR source code

A quick glance at the git showlog gives a rough estimate (there might be duplicates) of the number of committers:

$ git log --format='%aN' | sort -u | wc -l

This is a conservative estimation of the people that not only bothered to read the code, but even contributed to it.

As a comparison this is the same command run on GNUPG's git repository, the library that everyone uses to encrypt emails and sign software in the Linux world:

$ git log --format='%aN' | sort -u | wc -l 

An other indicator of the attention that Tor is getting might be activity on Tor's bugtracker timeline, where it's not uncommon to have more than 100 different actions per day, by a lot of different people.

Paul Syverson (from the US NRL) is the original designer (not developer) of most of implementation. The last version of TOR is the perfect example: all major changes are coming from the US NRL.

We already debunked this by looking at the git commit history.

No official statement revels that the US government is helping the TOR network but all the information gathered during our study seems to confirm that the US government is still deeply involved in the TOR project

The sponsors page is public, and lists every major sponsors. The fact that the US government is giving grants to researcher to study anonymity and resilience is pretty healthy for the Tor Project, and doesn't mean, at all, that the US government is "deeply involved" in the project. At least not significatively more that the other major donators like the EFF, Human right Watch, Google, the Freedom of the Press Foundation, Reddit, …

This study is not claiming breaking the TOR network or affirms that the US government is the real organization behind the TOR project.

This blogpost is not claiming that E. Filiol is a clown, nor affirms that he hasn't done any worthy contribution to computer science in years.

However favoring such a network would be a clear violation of the Wassenaar Agreement ( unless some sort of control is in place in a way or another (Filiol, 2013).

The paper cited here (Filiol, 2013) is "The Control of Technology by Nation States – Past, Present and Future – The Case of cryptology and Information Security”, Journal in Information Warfare, vol. 12, issue 3, pp. 1—10, October 2013.", published behind a paywall. Fortunately, it's possible to access it via Google books. In this paper, Filiol is speaking mostly about France, while The Tor Project, Inc. is an American entity, but this doesn't matter much in our case.

Since I'm not a lawyer, I asked a good friend of mine, who happens to be a legal advisor, specialised in international and French business' Law, to help me with this part.

The List of Dual -Use Goods and Technologies and Munitions List states that "Controls do not apply to "technology" "in the public domain", to "basic scientific research" or to the minimum necessary in formation for patent applications.".

A quick looks at the definition part of the document shows the following: "In the public domain": This means "technology" or "software" which has been made available without restrictions upon its further dissemination. Note: Copyright restrictions do not remove "technology" or "software" from being "in the public domain".

This is the case of Tor, and other Free (as in freedom) software, that are thus not subject to the Wassenaar Agreement, at all. A quick glance at the comprehensive FAQ from rapid7 about the Wassenaar Arrangement, or the small blog post from GNU confirms our interpretation.

This study aims at informing TOR users and to make them aware of network like the TOR network and the possible reality behind. Customers need to be informed before using any network who claims to protect your privacy and anonymity.

This blogpost aims at informing the public and to make it aware of charlatans like E. Filiol and the possible reality behind. People need to be informed before citing any work from this person, inviting him at conferences, or asking his opinion.


This is a botched paper in broken English, filled with approximations and sheer inventions about Tor.

@pastly February 22, 2021 - 14:37 • 15 days ago
Tor is not 'TOR' nor is it 'The Onion Router'

Warning: pedantry. I'm writing this down once so I have something to refer to in the future when I want to find this PDF again.

Dr. Paul Syverson is "the father of onion routing." He and his colleagues at NRL 20 years ago created onion routing, and he plus Nick Mathewson and Roger Dingleline wrote the origin tor code (adapted from code Matej Pfajfar wrote) in the early 2000s.

In short: Dr. Syverson is an authority figure in this space and knows what he's talking about. He was there and he is a primary source.

In 2011 he gave a keynote at ACSAC about the history of onion routing. The PDF is located here. The paragraphs before section 4.1 on page 129 explain how

  1. It's not "TOR" and never was.

    It was also [Roger's] decision that it should be written ‘Tor’ not ‘TOR’. Making it more of an ordinary word in this way also emphasizes the overlap of meaning with the German word ‘Tor’, which is gate (as in a city gate).

  2. It does not stand for "The Onion Router."

    Thus, when [Roger] told people he was working on onion routing, they would ask him which one. He would respond that it was the onion routing, the original program of projects from NRL. It was Rachel Greenstadt who noted to him that this was a nice acronym and gave Tor its name. Roger then observed that it also works well as a recursive acronym, ‘Tor’s onion routing’.

If you must consider "Tor" to be an acronym, it stands for "the onion routing," not "the onion router." To stay internally consistent, I begrudgingly admit that Tor is an acronym, since this post is framed as pedantic and I'm-more-technically-correct-than-you.

My personal opinion: the """war""" on what the acronym stands for has been lost. The spelling """war""" is still worth fighting.

@blog February 15, 2021 - 18:05 • 22 days ago
New Release: Tor
New Release: Tor nickm February 15, 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 on the download page. Packages should be available within the next several weeks, with a new Tor Browser likely next week.

The Tor 0.4.5.x release series is dedicated to the memory of Karsten Loesing (1979-2020), Tor developer, cypherpunk, husband, and father. Karsten is best known for creating the Tor metrics portal and leading the metrics team, but he was involved in Tor from the early days. For example, while he was still a student he invented and implemented the v2 onion service directory design, and he also served as an ambassador to the many German researchers working in the anonymity field. We loved him and respected him for his patience, his consistency, and his welcoming approach to growing our community.

This release series introduces significant improvements in relay IPv6 address discovery, a new "MetricsPort" mechanism for relay operators to measure performance, LTTng support, build system improvements to help when using Tor as a static library, and significant bugfixes related to Windows relay performance. It also includes numerous smaller features and bugfixes.

Below are the changes since For a list of changes since, see the ChangeLog file.

Changes in version - 2021-02-15

  • Major features (build):
    • When building Tor, first link all object files into a single static library. This may help with embedding Tor in other programs. Note that most Tor functions do not constitute a part of a stable or supported API: only those functions in tor_api.h should be used if embedding Tor. Closes ticket 40127.
  • Major features (metrics):
    • Introduce a new MetricsPort which exposes, through an HTTP interface, a series of metrics that tor collects at runtime. At the moment, the only supported output format is Prometheus data model. Closes ticket 40063. See the manual page for more information and security considerations.


  • Major features (relay, IPv6):
    • The torrc option Address now supports IPv6. This unifies our address discovery interface to support IPv4, IPv6, and hostnames. Closes ticket 33233.
    • Launch IPv4 and IPv6 ORPort self-test circuits on relays and bridges. Closes ticket 33222.
    • Relays now automatically bind on IPv6 for their ORPort, unless specified otherwise with the IPv4Only flag. Closes ticket 33246.
    • When a relay with IPv6 support is told to open a connection to another relay, and the extend cell lists both IPv4 and IPv6 addresses, the first relay now picks randomly which address to use. Closes ticket 33220.
    • Relays now track their IPv6 ORPort reachability separately from the reachability of their IPv4 ORPort. They will not publish a descriptor unless _both_ ports appear to be externally reachable. Closes ticket 34067.
  • Major features (tracing):
    • Add event-tracing library support for USDT and LTTng-UST, and a few tracepoints in the circuit subsystem. More will come incrementally. This feature is compiled out by default: it needs to be enabled at configure time. See documentation in doc/HACKING/ Closes ticket 32910.
  • Major bugfixes (directory cache, performance, windows):
    • Limit the number of items in the consensus diff cache to 64 on Windows. We hope this will mitigate an issue where Windows relay operators reported Tor using 100% CPU, while we investigate better solutions. Fixes bug 24857; bugfix on
  • Major bugfixes (relay, windows):
    • Fix a bug in our implementation of condition variables on Windows. Previously, a relay on Windows would use 100% CPU after running for some time. Because of this change, Tor now require Windows Vista or later to build and run. Fixes bug 30187; bugfix on (This bug became more serious in with the introduction of consensus diffs.) Patch by Daniel Pinto.
  • Major bugfixes (TLS, buffer):
    • When attempting to read N bytes on a TLS connection, really try to read all N bytes. Previously, Tor would stop reading after the first TLS record, which can be smaller than the N bytes requested, and not check for more data until the next mainloop event. Fixes bug 40006; bugfix on
  • Minor features (address discovery):
    • If no Address statements are found, relays now prioritize guessing their address by looking at the local interface instead of the local hostname. If the interface address can't be found, the local hostname is used. Closes ticket 33238.
  • Minor features (admin tools):
    • Add a new --format argument to -key-expiration option to allow specifying the time format of the expiration date. Adds Unix timestamp format support. Patch by Daniel Pinto. Closes ticket 30045.
  • Minor features (authority, logging):
    • Log more information for directory authority operators during the consensus voting process, and while processing relay descriptors. Closes ticket 40245.
  • Minor features (bootstrap reporting):
    • When reporting bootstrapping status on a relay, do not consider connections that have never been the target of an origin circuit. Previously, all connection failures were treated as potential bootstrapping failures, including connections that had been opened because of client requests. Closes ticket 25061.
  • Minor features (build):
    • When running the configure script, try to detect version mismatches between the OpenSSL headers and libraries, and suggest that the user should try "--with-openssl-dir". Closes 40138.
    • If the configure script has given any warnings, remind the user about them at the end of the script. Related to 40138.
  • Minor features (configuration):
    • Allow using wildcards (* and ?) with the %include option on configuration files. Closes ticket 25140. Patch by Daniel Pinto.
    • Allow the configuration options EntryNodes, ExcludeNodes, ExcludeExitNodes, ExitNodes, MiddleNodes, HSLayer2Nodes and HSLayer3Nodes to be specified multiple times. Closes ticket 28361. Patch by Daniel Pinto.
  • Minor features (control port):
    • Add a DROPTIMEOUTS command to drop circuit build timeout history and reset the current timeout. Closes ticket 40002.
    • When a stream enters the AP_CONN_STATE_CONTROLLER_WAIT status, send a control port event. Closes ticket 32190. Patch by Neel Chauhan.
    • Introduce GETINFO "stats/ntor/{assigned/requested}" and "stats/tap/{assigned/requested}" to get the NTor and TAP circuit onion handshake counts respectively. Closes ticket 28279. Patch by Neel Chauhan.
  • Minor features (control port, IPv6):
    • Tor relays now try to report to the controller when they are launching an IPv6 self-test. Closes ticket 34068.
    • Introduce "GETINFO address/v4" and "GETINFO address/v6" in the control port to fetch the Tor host's respective IPv4 or IPv6 address. We keep "GETINFO address" for backwards-compatibility. Closes ticket 40039. Patch by Neel Chauhan.
  • Minor features (directory authorities):
    • Add a new consensus method 30 that removes the unnecessary "=" padding from ntor-onion-key. Closes ticket 7869. Patch by Daniel Pinto.
    • Directory authorities now reject descriptors from relays running Tor versions from the obsolete 0.4.1 series. Resolves ticket 34357. Patch by Neel Chauhan.
    • The AssumeReachable option no longer stops directory authorities from checking whether other relays are running. A new AuthDirTestReachability option can be used to disable these checks. Closes ticket 34445.
    • When looking for possible Sybil attacks, also consider IPv6 addresses. Two routers are considered to have "the same" address by this metric if they are in the same /64 network. Patch from Maurice Pibouin. Closes ticket 7193.
  • Minor features (directory authorities, IPv6):
    • Make authorities add their IPv6 ORPort (if any) to the trusted servers list. Authorities previously added only their IPv4 addresses. Closes ticket 32822.
  • Minor features (documentation):
    • Mention the "!badexit" directive that can appear in an authority's approved-routers file, and update the description of the "!invalid" directive. Closes ticket 40188.
  • Minor features (ed25519, relay):
    • Save a relay's base64-encoded ed25519 identity key to the data directory in a file named fingerprint-ed25519. Closes ticket 30642. Patch by Neel Chauhan.
  • Minor features (heartbeat):
    • Include the total number of inbound and outbound IPv4 and IPv6 connections in the heartbeat message. Closes ticket 29113.
  • Minor features (IPv6, ExcludeNodes):
    • Handle IPv6 addresses in ExcludeNodes; previously they were ignored. Closes ticket 34065. Patch by Neel Chauhan.
  • Minor features (logging):
    • Add the running glibc version to the log, and the compiled glibc version to the library list returned when using --library-versions. Patch from Daniel Pinto. Closes ticket 40047.
    • Consider an HTTP 301 response to be an error (like a 404) when processing a directory response. Closes ticket 40053.
    • Log directory fetch statistics as a single line. Closes ticket 40159.
    • Provide more complete descriptions of our connections when logging about them. Closes ticket 40041.
    • When describing a relay in the logs, we now include its ed25519 identity. Closes ticket 22668.
  • Minor features (onion services):
    • Only overwrite an onion service's existing hostname file if its contents are wrong. This enables read-only onion-service directories. Resolves ticket 40062. Patch by Neel Chauhan.
  • Minor features (pluggable transports):
    • Add an OutboundBindAddressPT option to allow users to specify which IPv4 and IPv6 address pluggable transports should use for outgoing IP packets. Tor does not have a way to enforce that the pluggable transport honors this option, so each pluggable transport needs to implement support on its own. Closes ticket 5304.
  • Minor features (protocol, proxy support, defense in depth):
    • Respond more deliberately to misbehaving proxies that leave leftover data on their connections, so as to make Tor even less likely to allow the proxies to pass their data off as having come from a relay. Closes ticket 40017.
  • Minor features (relay address tracking):
    • We now store relay addresses for OR connections in a more logical way. Previously we would sometimes overwrite the actual address of a connection with a "canonical address", and then store the "real address" elsewhere to remember it. We now track the "canonical address" elsewhere for the cases where we need it, and leave the connection's address alone. Closes ticket 33898.
  • Minor features (relay):
    • If a relay is unable to discover its address, attempt to learn it from the NETINFO cell. Closes ticket 40022.
    • Log immediately when launching a relay self-check. Previously we would try to log before launching checks, or approximately when we intended to launch checks, but this tended to be error-prone. Closes ticket 34137.
  • Minor features (relay, address discovery):
    • If Address option is not found in torrc, attempt to learn our address with the configured ORPort address if any. Closes ticket 33236.
  • Minor features (relay, IPv6):
    • Add an AssumeReachableIPv6 option to disable self-checking IPv6 reachability. Closes part of ticket 33224.
    • Add new "assume-reachable" and "assume-reachable-ipv6" consensus parameters to be used in an emergency to tell relays that they should publish even if they cannot complete their ORPort self- checks. Closes ticket 34064 and part of 33224.
    • Allow relays to send IPv6-only extend cells. Closes ticket 33222.
    • Declare support for the Relay=3 subprotocol version. Closes ticket 33226.
    • When launching IPv6 ORPort self-test circuits, make sure that the second-last hop can initiate an IPv6 extend. Closes ticket 33222.
  • Minor features (safety):
    • Log a warning at startup if Tor is built with compile-time options that are likely to make it less stable or reliable. Closes ticket 18888.
  • Minor features (specification update):
    • Several fields in microdescriptors, router descriptors, and consensus documents that were formerly optional are now required. Implements proposal 315; closes ticket 40132.
  • Minor features (state management):
    • When loading the state file, remove entries from the statefile that have been obsolete for a long time. Ordinarily Tor preserves unrecognized entries in order to keep forward-compatibility, but these entries have not actually been used in any release since before 0.3.5.x. Closes ticket 40137.
  • Minor features (statistics, ipv6):
    • Relays now publish IPv6-specific counts of single-direction versus bidirectional relay connections. Closes ticket 33264.
    • Relays now publish their IPv6 read and write statistics over time, if statistics are enabled. Closes ticket 33263.
  • Minor features (subprotocol versions):
    • Use the new limitations on subprotocol versions due to proposal 318 to simplify our implementation. Part of ticket 40133.
  • Minor features (testing configuration):
    • The TestingTorNetwork option no longer implicitly sets AssumeReachable to 1. This change allows us to test relays' self- testing mechanisms, and to test authorities' relay-testing functionality. Closes ticket 34446.
  • Minor features (testing):
    • Added unit tests for channel_matches_target_addr_for_extend(). Closes Ticket 33919. Patch by MrSquanchee.
  • Minor bugfixes (circuit padding):
    • When circpad_send_padding_cell_for_callback is called, `is_padding_timer_scheduled` flag was not reset. Now it is set to 0 at the top of that function. Fixes bug 32671; bugfix on
    • Add a per-circuit padding machine instance counter, so we can differentiate between shutdown requests for old machines on a circuit. Fixes bug 30992; bugfix on
    • Add the ability to keep circuit padding machines if they match a set of circuit states or purposes. This allows us to have machines that start up under some conditions but don't shut down under others. We now use this mask to avoid starting up introduction circuit padding again after the machines have already completed. Fixes bug 32040; bugfix on
  • Minor bugfixes (circuit, handshake):
    • In the v3 handshaking code, use connection_or_change_state() to change the state. Previously, we changed the state directly, but this did not pass the state change to the pubsub or channel objects, potentially leading to bugs. Fixes bug 32880; bugfix on Patch by Neel Chauhan.
  • Minor bugfixes (compilation):
    • Change the linker flag ordering in our library search code so that it works for compilers that need the libraries to be listed in the right order. Fixes bug 33624; bugfix on
    • Fix the "--enable-static-tor" switch to properly set the "-static" compile option onto the tor binary only. Fixes bug 40111; bugfix on
  • Minor bugfixes (configuration):
    • Exit Tor on a misconfiguration when the Bridge line is configured to use a transport but no corresponding ClientTransportPlugin can be found. Prior to this fix, Tor would attempt to connect to the bridge directly without using the transport, making it easier for adversaries to notice the bridge. Fixes bug 25528; bugfix on
  • Minor bugfixes (control port):
    • Make sure we send the SOCKS request address in relay begin cells when a stream is attached with the purpose CIRCUIT_PURPOSE_CONTROLLER. Fixes bug 33124; bugfix on 0.0.5. Patch by Neel Chauhan.
  • Minor bugfixes (crash, relay, signing key):
    • Avoid assertion failures when we run Tor from the command line with `--key-expiration sign`, but an ORPort is not set. Fixes bug 40015; bugfix on Patch by Neel Chauhan.
  • Minor bugfixes (logging):
    • Avoid a spurious log message about missing subprotocol versions, when the consensus that we're reading from is older than the current release. Previously we had made this message nonfatal, but in practice, it is never relevant when the consensus is older than the current release. Fixes bug 40281; bugfix on
    • Remove trailing whitespace from control event log messages. Fixes bug 32178; bugfix on Based on a patch by Amadeusz Pawlik.
    • Turn warning-level log message about SENDME failure into a debug- level message. (This event can happen naturally, and is no reason for concern). Fixes bug 40142; bugfix on
    • When logging a rate-limited message about how many messages have been suppressed in the last N seconds, give an accurate value for N, rounded up to the nearest minute. Previously we would report the size of the rate-limiting interval, regardless of when the messages started to occur. Fixes bug 19431; bugfix on
  • Minor bugfixes (onion services):
    • Avoid a non-fatal assertion in certain edge-cases when establishing a circuit to an onion service. Fixes bug 32666; bugfix on
  • Minor bugfixes (rust, protocol versions):
    • Declare support for the onion service introduction point denial of service extensions when building with Rust. Fixes bug 34248; bugfix on
    • Make Rust protocol version support checks consistent with the undocumented error behavior of the corresponding C code. Fixes bug 34251; bugfix on
  • Minor bugfixes (self-testing):
    • When receiving an incoming circuit, only accept it as evidence that we are reachable if the declared address of its channel is the same address we think that we have. Otherwise, it could be evidence that we're reachable on some other address. Fixes bug 20165; bugfix on
  • Minor bugfixes (spec conformance):
    • Use the correct key type when generating signing->link certificates. Fixes bug 40124; bugfix on
  • Minor bugfixes (subprotocol versions):
    • Consistently reject extra commas, instead of only rejecting leading commas. Fixes bug 27194; bugfix on
    • In summarize_protover_flags(), treat empty strings the same as NULL. This prevents protocols_known from being set. Previously, we treated empty strings as normal strings, which led to protocols_known being set. Fixes bug 34232; bugfix on Patch by Neel Chauhan.
  • Code simplification and refactoring:
    • Add and use a set of functions to perform down-casts on constant connection and channel pointers. Closes ticket 40046.
    • Refactor our code that logs descriptions of connections, channels, and the peers on them, to use a single call path. This change enables us to refactor the data types that they use, and eliminates many confusing usages of those types. Closes ticket 40041.
    • Refactor some common node selection code into a single function. Closes ticket 34200.
    • Remove the now-redundant 'outbuf_flushlen' field from our connection type. It was previously used for an older version of our rate-limiting logic. Closes ticket 33097.
    • Rename "fascist_firewall_*" identifiers to "reachable_addr_*" instead, for consistency with other code. Closes ticket 18106.
    • Rename functions about "advertised" ports which are not in fact guaranteed to return the ports that have been advertised. Closes ticket 40055.
    • Split implementation of several command line options from options_init_from_torrc into smaller isolated functions. Patch by Daniel Pinto. Closes ticket 40102.
    • When an extend cell is missing an IPv4 or IPv6 address, fill in the address from the extend info. This is similar to what was done in ticket 33633 for ed25519 keys. Closes ticket 33816. Patch by Neel Chauhan.
  • Deprecated features:
    • The "non-builtin" argument to the "--dump-config" command is now deprecated. When it works, it behaves the same as "short", which you should use instead. Closes ticket 33398.
  • Documentation:
    • Replace URLs from our old bugtracker so that they refer to the new bugtracker and wiki. Closes ticket 40101.
  • Removed features:
    • We no longer ship or build a "tor.service" file for use with systemd. No distribution included this script unmodified, and we don't have the expertise ourselves to maintain this in a way that all the various systemd-based distributions can use. Closes ticket 30797.
    • We no longer ship support for the Android logging API. Modern versions of Android can use the syslog API instead. Closes ticket 32181.
    • The "optimistic data" feature is now always on; there is no longer an option to disable it from the torrc file or from the consensus directory. Closes part of 40139.
    • The "usecreatefast" network parameter is now removed; there is no longer an option for authorities to turn it off. Closes part of 40139.
  • Testing:
    • Add unit tests for bandwidth statistics manipulation functions. Closes ticket 33812. Patch by MrSquanchee.
  • Code simplification and refactoring (autoconf):
    • Remove autoconf checks for unused funcs and headers. Closes ticket 31699; Patch by @bduszel
  • Code simplification and refactoring (maintainer scripts):
    • Disable by default the pre-commit hook. Use the environment variable TOR_EXTRA_PRE_COMMIT_CHECKS in order to run it. Furthermore, stop running practracker in the pre-commit hook and make check-local. Closes ticket 40019.
  • Code simplification and refactoring (relay address):
    • Most of IPv4 representation was using "uint32_t". It has now been moved to use the internal "tor_addr_t" interface instead. This is so we can properly integrate IPv6 along IPv4 with common interfaces. Closes ticket 40043.
  • Documentation (manual page):
    • Move them from doc/ to doc/man/. Closes ticket 40044.
    • Describe the status of the "Sandbox" option more accurately. It is no longer "experimental", but it _is_ dependent on kernel and libc versions. Closes ticket 23378.
  • Documentation (tracing):
    • Document in depth the circuit subsystem trace events in the new doc/tracing/ Closes ticket 40036.
  • Removed features (controller):
    • Remove the "GETINFO network-status" controller command. It has been deprecated since Closes ticket 22473.
@blog February 12, 2021 - 18:50 • 24 days ago
Bug Smash Fund, Year 2: Progress So Far!
Bug Smash Fund, Year 2: Progress So Far! Al Smith February 12, 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 134 tickets with BugSmashFund. As of today, 97 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, defense against DDoS on onion services v3, GetTor, Arti, and security fixes. We have also used the Bug Smash Fund to create a new page, which will act as a landing place for network and service status updates.
Thanks for supporting this work!
Below is a list of many of the tickets we’ve closed so far.

Continuous integration tooling

When we made the transition from Trac to GitLab for issue tracking, we moved our CI tooling into GitLab CI and Appveyor. Because this work is critical--but not covered by a grant--the Bug Smash Fund helped us to fix the CI pipeline in GitLab and improve the infrastructure we use to develop Tor. See all CI tickets.

Tor Browser

The Bug Smash Fund helps us to resolve issues in Tor Browser that are not part of a grant or sponsored project, including fixing AV1 playback. It has also helped us make updates to Tor Browser's custom UI.

Network Health

Over the last month, overload bugs on the directory authorities have caused v3 onion services to become unreliable. The Bug Smash Fund was critical here--it allowed us to pivot from other work to address these issues.

Tor Network Status

We were in need of a clear, easy-to-read place to share updates on the status of the Tor network when there have been disruptions. The Bug Smash Fund allowed us to set up Let us know what you think! We also fixed Schleuder, a tool we use to communicate with encrypted email to/from (#40002).
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 just add “Bug Smash Fund” into the comment field, and we’ll make sure it’s directed to the right place.
@blog February 11, 2021 - 12:06 • 26 days ago
Onionize your Workflow with the Onion Guide Fanzine
Onionize your Workflow with the Onion Guide Fanzine Gaba February 11, 2021

At the Tor Project, we build technologies that allow anybody to access the Internet privately. We maintain the software that runs the Tor network as well as utilities and clients to use the network. We also collect anonymous data on the network that allows us to detect problems that may occur, and we connect with the users of the Tor network through training and feedback exercises that help to improve our tools.

In some places, the organizations and individuals we work with are in risk of persecution for the digital services they run. It could be reproductive rights services that are criminalized in some countries or content that is censored by an Internet provider or government. Or it could be that they need to protect their own users when accessing their content and find a way for their community to use Tor Browser for protection.
One way we help human rights defenders and organizations take back their right to privacy online is by helping them to use and set up onion services. Websites that are only accessible over Tor are called "onions" and end in the TLD .onion. For example, the DuckDuckGo onion is https://3g2upl4pq6kufc4m.onion. You can access these websites by using Tor Browser. The addresses must be shared with you by the website host, as onions are not indexed in search engines in the typical way that other websites are.
Last year, thanks to the support of Digital Defenders Partnership, we wrote a series of Onion Guides intended to make it easier for our partners to correctly and safely set up their own onion services. To create these Onion Guides, we collected and improved existing disparate information about the benefits of onion services and how to set them up for a website. 
During the last activity of this project, we ran a survey between December 2020 and January 2021. The participants were partner organizations and individuals who were known to use onion services and had received training from Tor in the past. All questions asked were related to the Onion Guides and onion services. Five people responded to this survey.
“[Tor] offers the possibility for those of us who do work for social transformation to access the Internet safely, without exposing ourselves or exposing our processes, but also, it is a tool that is there and can be even more accessible to different people in different territories.” - Survey response.
When asked if they can define onion services, all participants in this study gave different answers. Some related to specific services, like OnionShare and SecureDrop; others associated onion services to a service without metadata; only two participants answered that it is a service that can only be accessed over the Tor network.
When asked if onion services respond to the threats they or their organizations face, most participants answered YES. One of the participants answered NO. Same for the question asking if you feel safer using onion services.
When asked to define the best benefit of using onion services, most participants answered (a) anonymity; followed by (b) accessing digital security guides and tools; other mentions were: (c) sharing and storing documents and sensitive information; and (d) NAT punching.
When asked if they would recommend onion services to anyone, all survey participants answered YES, because of safety.
You can find the Onion Guide in our community portal, well as the section on Onion Services, in English, Spanish and Portuguese. Feel free to use it to set up your own .onion site, and let us know how it works for you.
@kushal February 11, 2021 - 04:30 • 26 days ago
Defending against side channel attacks via dependencies

Yesterday Alex Birsan posted a blog explaining how he made a supply chain attack on various companies via dependencies. I was waiting for this blog from last August when we noticed the mentioned packages on PyPI (and removed). I reached out to Alex to figure out more about the packages, and he said he will write a blog post.

This is the same time when @rsobers also tweeted about how any similar attack works via DNS.

dns data exfiltration

At SecureDrop project, we spend a lot of time figuring out a way to defend against similar attacks. My PyCon US 2019 talk explained the full process. In simple words, we are doing the following:

  • Verify the source of every python dependency before adding/updating them. This is a manual step done by human eyes.
  • Build wheels from the verified source and store them into a package repository along with OpenPGP signed sha256sums.
  • Before building the Debian package, make sure to verify the OpenPGP signature, and also install only from the known package repository using verified (again via OpenPGP signature) wheel hashes (from the wheels we built ourselves).

Now, in the last few months, we modified these steps, and made it even easier. Now, all of our wheels are build from same known sources, and all of the wheels are then built as reproducible and stored in git (via LFS). The final Debian packages are again reproducible. Along with this and the above mentioned OpenPGP signature + package sha256sums verification via pip. We also pass --no-index the argument to pip now, to make sure that all the dependencies are getting picked up from the local directory.

Oh, and I also forgot to mention that all of the project source tarballs used in SecureDrop workstation package building are also reproducible. If you are interested in using the same in your Python project (or actually for any project's source tarball), feel free to have a look at this function.

There is also diff-review mailing list (very low volume), where we post a signed message of any source package update we review.

@blog February 9, 2021 - 15:40 • 28 days ago
Anonymous GitLab Ticketing: An Exciting New Project at Tor
Anonymous GitLab Ticketing: An Exciting New Project at Tor Maria Violante February 09, 2021

Hi! My name is Maria Violante, and I’m one of two Outreachy interns for Tor Project for Winter 2020/2021. I’m thrilled to share with you the results of my internship thus far: the Anonymous Ticket Portal, which allows individuals to submit instant, anonymous tickets to participate in GitLab repos without signing up for a GitLab account or disclosing any personal data.

Keep reading to find out how you can participate in and benefit from the Anonymous Ticket Portal!

Why Anonymous Ticketing?

Currently, before making a bug report to one of Tor’s repos, users must sign up for a GitLab account via the TicketLobby ( Although this is the right approach for many users, it has its limitations:

  • It’s overkill for the occasional or one-time bug reporter.
  • The delay between requesting a GitLab account and approval by a moderator means bug reports are lost, as people may not return to submit their bug or remember the circumstances that provoked the bug in the first place.
  • Many privacy-focused Tor users don’t feel comfortable providing their email for a bug report.

This anonymous ticketing portal is designed to circumvent these limitations, resulting in more complete, private bug reporting, and includes the following features:

Lightning-fast, Anonymous (and Lazy) User Interface

Instead of username and password, the Anonymous Ticket Portal's authentication system mirrors Freedom of the Press Foundation's Secure Drop (, in that potential bug reporters receive a code phrase of six random words from the EFF’s New Wordlists for Random Passphrases. (

An example of the code phrase creation screen. A purple bar with the Tor Logo at the top, followed by instructions to create a code phrase. At the bottom is a list of six random words in purple.
(An example of user identifier code phrase generation.)

Once the user approves their code phrase, they are redirected to a bookmarkable landing page that allows them to browse and search projects and issues or instantly create their first issue/note using GitLab Flavored Markdown (

A view of the user landing page. The top displays the code phrase that was created by the user. This is followed by a list of actions the user can take and lists of items the user has already created, including their status (pending or approved.)
(A sample user landing view.)

As they navigate through the system, their user identifier code phrase is passed forward via an arg/kwarg in the URL, which is checked against an authenticator that determines it meets all the parameters for a user identifier (e.g., approved words only, right number of words, etc.).

Once a contribution is made, it’s saved in the database for moderation. Users can return to their landing page at any time, either via bookmark or by manually entering their code-phrase into a ‘login’ screen, and make new contributions or check the status of their pending items.

A login screen showing six fields, one for each word of the code phrase.
(The login view for returning users that do not want to use bookmarks.)

Tor-Flavored, Data-Packed, Familiar Project and Issue Views:   

Project and issue templates are laid out to mirror a repo’s gitlab instance for a more familiar user experience, and styled via Bootstrap and the Tor Project Styleguide’s CSS files ( to maintain a strong visual identity and build user trust. Additionally, views display a project or issue’s GitLab milestones, labels, and notes, as well as a link directly to the relevant listing on GitLab.

A screen showing a list of projects that use the Anon-Ticket project. Each project has a link that says
(A project list view.)
A detail view of the snowflake project, with open issues at the top and closed issues at the bottom. A link near the top advises the user they can go back to their landing page or create a new issue.
(Example of a Project Detail View - This one for the Snowflake repo.)
An example of a closed issue view. The top shows details about the issue from gitlab, including the namespace, issue number, assignee, milestones, labels, etc. This is followed by a detail summary and a list of project notes.
(Example of an issue detail view.)

Feature-Rich Bulk Moderation:

The Anonymous Ticket Portal leverages Django’s robust User and Group system to manage Moderator permissions. 

Logged-in moderators have access to a feature-rich view that includes project/issue details, creation timestamps, linked User Identifier code phrases, and the option to bulk approve or reject a theoretically unlimited number of pending items at once.

A screenshot of the moderator view, showing sample notes and issues, with dropdowns for status or to update. Buttons at the bottom allow the moderators to save all changes, change password, or logout.
(An example of the moderator portal - the status on many items can be set at once, or moderators can update the details of a single item.)

Additionally, each object has an “update view,” allowing moderators to tweak descriptions/content as necessary (e.g., for errors or unclear language), and add moderator-only comments that cannot be viewed by the user.

A screenshot of the view to update a moderator note, displaying a form with fields that the moderator can update, such as title, body, reviewer status. Moderators can also a mod-specific comment.
(A screenshot of the the moderator view for updating an issue. Note the ability to add moderator only comments.)

Super-Powered SuperUser

By leveraging the python-gitlab package and custom save definitions, a new project can be added to the Anonymous Ticket Portal using only a single piece of data--the project’s valid GitLab ID number. All details about the project (such as description, web url, name, groups, and namespace) are instantly fetched from GitLab upon project save--and can be updated by simply resaving the project.

Additionally, groups are created and updated programmatically via a custom BaseCommand on the command line, which increases consistency in both usage and with testing.

Try It Out!

A test instance of this project is currently live at, or you can see the repo itself at

The following repos are currently set up to take anonymous issue reporting through the Anonymous Ticket Portal:

  • The Tor Project / Core / Tor
  • The Tor Project / Applications / Tor Browser
  • The Tor Project / Anti-censorship / Pluggable Transports / Snowflake
  • The Tor Project / Anti-censorship / Pluggable Transports / Snowflake WebExtension
  • George Kadianakis / onionbalance
  • The Tor Project / TPA / Anonymous Ticket Portal (This repo!)

Additionally, we are currently looking for volunteers to add their Tor GitLab repo as a test project for the Anonymous Ticket Portal and try out being a moderator. If you are part of the mailing list that received an email about this project, please consider volunteering your repo; your feedback will allow us to make this project as effective and user-friendly as possible for Tor users, developers, and moderators.

You can also (and are highly encouraged to) submit issues and notes on the project itself to GitLab via the the Anonymous Ticket Portal (

Planned Improvements

We have a number of planned features rolling out over the next few weeks, including:

  • Launching as an onion service.
  • The ability to create GitLab account requests with the intention of eventually replacing the TicketLobby. Users will be able to link their GitLab account request to their user identifier if they want the ability to check the status of their request in the web portal (thus lowering demands on moderators), but will also be able to create GitLab Account Requests without being logged in to the Anonymous Ticket Portal system.
  • Additional security features, such as improved rate-limiting, etc.


@blog February 8, 2021 - 20:03 • 28 days ago
Tor in the Media: 2020
Tor in the Media: 2020 Al Smith February 08, 2021

This year, we’re continuing a new tradition of reviewing media and news stories that mentioned Tor and the Tor Project. Our goal is to highlight what is changing (or not) in the conversation about privacy and censorship, as well as identifying the ways the media discusses Tor in the context of these challenges.

When everything changed

Last year started off on a “normal” note--we were preparing to dive into our roadmap for 2020, and news outlets were publishing articles explaining Tor, demonstrating how to use Tor Browser to protect your privacy online, and highlighting how privacy is a human right Tor fights to make available for everyone online. And then COVID-19 changed everything.

When the pandemic hit the Tor Project, we had to make some hard decisions that became headline news: Tor Project lays off a third of its staff 4/18/2020, and COVID-19 forces Tor Project to lay off a third of its staff 4/19/2020.

Use Tor, fight the surveillance pandemic

The COVID-19 pandemic changed everything, and to be online became an even more essential part of our daily lives. Many people began to understand that privacy online is now more important than ever. Journalists began looking for advice to give their readers about protecting their privacy, and we became ‘rule #11’ on how to ensure cyber security while working from home:

11. Secure browsing

If you want an extra layer of security and privacy, it is a good idea to install the Tor browser. It comes with many security features, which makes Web-based attacks difficult to execute on your computer.

Throughout the year, other outlets continued writing stories that highlight Tor as a tool to protect your privacy online. TechRadar and Vice both cited Tor in articles about how “incognito mode” is not enough to protect users’ privacy.

The uprising for Black Lives during the summer raised the concern about state surveillance of activists, a topic discussed at our third PrivChat, with Snowden as the panel moderator. Motherboard wrote a great guide to avoiding state surveillance in which Tor is cited, and Freedom of the Press also wrote a comprehensive guide to ‘pick your browser’ that compared the privacy features in Tor Browser, Firefox, Brave, and Chrome. Tor Browser and other apps that use Tor were part of the Mashable list of ‘apps you should have downloaded in 2020.’ ExpressVPN wrote an article describing the benefits of integrating Tor to apps, and recommended just building the services with onion services so Tor (and privacy) is part of an app’s design by default.

Last year showed us that now, more than ever, we have to keep working on Tor to make it easier to use and more accessible for more people. The results of this work made the news as well:

Onion Services improvements

The Tor Browser 9.5 release introduced new onion service features that improved the user experience. Changes include Onion-Location, a feature that makes it much easier for users to find and return to an .onion version of a website, a popular feature that made it easier to find secure onion services; improved onion services error messages; and the ability for administrators to password-protect .onion pages. This work was covered by PCMagazine, ZDNet, ghacks and BleepingComputer.

This year we also announced the depreciation timeline for onion services v2. We aim to completely disable onion services v2 by October 15, 2021. Some projects have already migrated to v3, including Bitcoin Core, as was covered by

And finally, we rolled out a prototype for human readable names for onion services in partnership with the SecureDrop team, who wrote about this process on their blog.

Tor Browser releases

The Tor Browser 10.0 release is the first stable release of the 10.0 series based on Firefox 78esr--it included important security updates from Firefox and was covered by BleepingComputer and TechRadar. Following this release, we reached an important milestone, which was to bring Tor Browser for Android to the new Android Firefox release Fenix--an effort that involved many months of design and development. Many news outlets covered our work, such as ghacks, Times of India, Android Police, and Softpedia News.

Combating DDoS on onion services

Our proposals (that are in the works, not yet shipped) on how to solve DDoS attacks against onion services received attention from several outlets, including BleepingComputer, TechRadar and Tech Leash, wrote about these proposals. CoinDesk published an article focused on our tokens proposal that we presented at our State of the Onion in November last year.

Network Performance

The Daily Swig wrote about our very important work to improve the Tor network’s performance, making it faster for users, that we started in 2020.. Our goal is to improve one of the number one usability issues with Tor: that it’s too slow. Keep following the blog for more news on these improvements.

Other wins

Even though 2020 started with so many uncertainties and unknowns, we also had some important successes, and we are happy to share a few stories that make us proud.

Belarus censorship circumvention

This year, internet users in Belarus faced censorship, and Tor helped to provide them with circumvention. Decrypt wrote how Tor saw a surge in use during the protests in Belarus, and Benzinga did a great in-depth article about how Tor combats internet censorship.

Mexico unblocks Tor

After many months of persistent work, volunteers and researches from the Tor community in Mexico not only managed to discover how the largest telecommunications operator in Mexico was blocking Tor, but also managed to contact them, get them to change their policies and stop blocking Tor, and convince them to run Tor relays and contribute to the network. This is a huge win for internet privacy and anti-censorship advocacy. GlobalVoices published an article in English and Spanish detailing the whole story.

Launch of Tor’s Membership Program

CoinDesk wrote about the Tor Project’s new Membership Program, a program we launched in 2020 and of which we are very proud. The Membership Program is designed to build a supportive relationship between our nonprofit and private sector organizations that use our technology or want to support our mission.

@blog February 7, 2021 - 15:45 • 30 days ago
New Release: Tor Browser 10.5a10 (Windows Only)
New Release: Tor Browser 10.5a10 (Windows Only) sysrqb February 07, 2021

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

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

This version updates Firefox to 78.7.1esr for Windows. This release includes important security updates to Firefox.

The full changelog since Tor Browser 10.5a8 is:

  • Windows
    • Update Firefox to 78.7.1esr
@blog February 7, 2021 - 15:32 • 30 days ago
New Release: Tor Browser 10.5a9 (Android Only)
New Release: Tor Browser 10.5a9 (Android Only) sysrqb February 07, 2021

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

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

This release updates Fenix to 86.0.0-beta.2. Additionally, we update NoScript to 11.2 and HTTPS Everywhere to 2021.1.27.

The full changelog since Tor Browser 10.5a8 is:

  • Android
    • Update Fenix to 86.0.0-beta.2
    • Update HTTPS Everywhere to 2021.1.27
    • Update NoScript to 11.2
    • Bug 40041: Rebase android-components patches for Fenix 86 beta 2 builds
    • Bug 40109: Reduce requested permissions
    • Bug 40141: Hide EME site permission
    • Bug 40143: Use deterministic date in Test apk
    • Bug 40146: Rebase Fenix patches to Fenix 86 beta 2
    • Bug 40188: Build and ship snowflake only if it is enabled
    • Bug 40212: Bump version of snowflake and webrtc
    • Bug 40308: Disable network partitioning until we evaluate dFPI
    • Bug 40309: Avoid using regional OS locales
    • Bug 40320: Rebase tor-browser patches to 86.0b5
  • Build System
    • Android
      • Bug 40214: Update AMO Collection URL
      • Bug 40217: Update components for switch to mozilla86-based Fenix
@blog February 7, 2021 - 04:16 • 1 months ago
New Release: Tor Browser 10.0.11 (Windows Only)
New Release: Tor Browser 10.0.11 (Windows Only) sysrqb February 06, 2021

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

This version updates Firefox to 78.7.1esr for Windows. This release includes important security updates to Firefox.

The full changelog since Desktop Tor Browser 10.0.10 is:

  • Windows
    • Update Firefox to 78.7.1esr
@blog February 4, 2021 - 03:31 • 1 months ago
New Release: Tor Browser 10.0.10
New Release: Tor Browser 10.0.10 sysrqb February 03, 2021

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

This version increases the availability of version 3 (v3) onion services. The fix is included in the recently released stable tor versions, as well.

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

@blog February 3, 2021 - 18:26 • 1 months ago
New releases: Tor,, and
New releases: Tor,, and nickm February 03, 2021

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

We're also releasing updates for older stable release series. You can download (changelog) and (changelog) from Note that the 0.4.3.x series will no longer be supported after 15 February.

Tor backports numerous bugfixes from later releases, including one that made v3 onion services more susceptible to denial-of-service attacks, and a feature that makes some kinds of DoS attacks harder to perform.

Changes in version - 2021-02-03

  • Major bugfixes (onion service v3, backport from
    • Stop requiring a live consensus for v3 clients and services, and allow a "reasonably live" consensus instead. This allows v3 onion services to work even if the authorities fail to generate a consensus for more than 2 hours in a row. Fixes bug 40237; bugfix on
  • Major feature (exit, backport from
    • Re-entry into the network is now denied at the Exit level to all relays' ORPorts and authorities' ORPorts and DirPorts. This change should help mitgate a set of denial-of-service attacks. Closes ticket 2667.


  • Minor feature (build system, backport from
    • New "make lsp" command to generate the compile_commands.json file used by the ccls language server. The "bear" program is needed for this. Closes ticket 40227.
  • Minor features (compilation, backport from
    • Disable deprecation warnings when building with OpenSSL 3.0.0 or later. There are a number of APIs newly deprecated in OpenSSL 3.0.0 that Tor still requires. (A later version of Tor will try to stop depending on these APIs.) Closes ticket 40165.
  • Minor features (crypto, backport from
    • Fix undefined behavior on our Keccak library. The bug only appeared on platforms with 32-byte CPU cache lines (e.g. armv5tel) and would result in wrong digests. Fixes bug 40210; bugfix on Thanks to Bernhard Übelacker, Arnd Bergmann and weasel for diagnosing this.
  • Minor bugfixes (compatibility, backport from
    • Strip '\r' characters when reading text files on Unix platforms. This should resolve an issue where a relay operator migrates a relay from Windows to Unix, but does not change the line ending of Tor's various state files to match the platform, and the CRLF line endings from Windows end up leaking into other files such as the extra-info document. Fixes bug 33781; bugfix on 0.0.9pre5.
  • Minor bugfixes (compilation, backport from
    • Fix a compilation warning about unreachable fallthrough annotations when building with "--enable-all-bugs-are-fatal" on some compilers. Fixes bug 40241; bugfix on
  • Minor bugfixes (SOCKS5, backport from
    • Handle partial SOCKS5 messages correctly. Previously, our code would send an incorrect error message if it got a SOCKS5 request that wasn't complete. Fixes bug 40190; bugfix on
  • Minor bugfixes (testing, backport from
    • Fix the `config/parse_tcp_proxy_line` test so that it works correctly on systems where the DNS provider hijacks invalid queries. Fixes part of bug 40179; bugfix on
    • Fix our Python reference-implementation for the v3 onion service handshake so that it works correctly with the version of hashlib provided by Python 3.9. Fixes part of bug 40179; bugfix on
    • Fix the `tortls/openssl/log_one_error` test to work with OpenSSL 3.0.0. Fixes bug 40170; bugfix on
@blog February 1, 2021 - 21:05 • 1 months ago
New release candidate: Tor
New release candidate: Tor nickm February 01, 2021

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

We think this is almost ready to be stable: please test it out, and let us know on the bugtracker if there are any major problems!

Tor is the third release candidate in its series. We're coming closer and closer to a stable release series. This release fixes an annoyance with address detection code, and somewhat mitigates an ongoing denial-of-service attack.

We anticipate no more code changes between this and the stable release, though of course that could change.

Changes in version - 2021-02-01

  • Major feature (exit):
    • Re-entry into the network is now denied at the Exit level to all relays' ORPorts and authorities' ORPorts and DirPorts. This change should help mitgate a set of denial-of-service attacks. Closes ticket 2667.
  • Minor bugfixes (relay, configuration):
    • Don't attempt to discover our address (IPv4 or IPv6) if no ORPort for it can be found in the configuration. Fixes bug 40254; bugfix on
@pastly January 13, 2021 - 15:56 • 2 months ago
Tracking Tor's network-wide V3 onion service outages

Major update 28 Jan 2021 (UTC): It's happening again, but this time the large amount of directory traffic is coming from exits. We've missed three consensuses, so v3 onions will be going down. Dirauths are already discussing and trading patches to mitigate the issue in the short term. The long-term solution for not allowing people to use exits to do this is tracked here. Read the main body of this post for more information on, e.g., what a "consensus" is and how not having them affects onion services.

It is January 13th, 2021 as I finish writing these initial words. Major updates may get a date stamp next to them.

Bottom line up front

  • Someone is sending the directory authorities (and fallback dirs) lots of traffic.
  • This causes the dirauths to no longer be able to reliably communicate.
  • This means consensuses are no longer reliably produced every hour.
  • No new consensus three hours in a row means new connections to v3 onion services stop working because of a bug. Existing connections survive, and no other part of Tor breaks at the three hour mark.
  • There is an alpha release for experts who know what they are doing. It is making its way into all supported stable Tor versions.

Please keep these facts in mind:

  • It is unknown if the traffic hitting the dirauths is maliciously motivated. People keep calling it an attack. I don't think we have the evidence to back that up at this time.

  • There is no evidence that the traffic overload is actively trying to hurt v3 onions. A similar situation existed last year and onions didn't go down then. Claims that it is "the" government or rival drug markets are not backed up with any evidence that I've seen.

If you have evidence of who is behind this traffic, please let someone know. Tor Project or me (blog comment, an email (listed on About Me), or IRC message)

While I currently work on Tor-related stuff for my job, nothing contained in this post has anything to do with my work. Everything contained in this post is public unclassified knowledge. Opinions expressed, if any, are my own.

Traffic starts hitting dirauths (again)

Roger points out on January 6th that "the overload is back".

It's not OMGWTFBBQ levels of traffic. It's not from one IP nor is it from IPs all over the Internet. One dirauth says it seems to be a poorly written custom Tor client requesting directory information too often.

Three missed consensuses

On January 9th, 10th, and 11th, there are repeated instances of 3 or more consensuses in a row that are not generated.

This is the trigger for v3 onions no longer working. Consensuses are generated every hour and are valid for 3 hours. Most parts of Tor (v2 onions, general circuit building, etc.) do not require a live (currently valid) consensus, but can get by just fine with a recently valid consensus (expired less than 24 hours ago).

January 12th saw a few missed consensuses, but never 3 in a row. No consensus has been missed so far on the 13th.

The bug and its fix

The v3 onion service code was written to require a live consensus, and it didn't need to be (devs are verifying this). The fix for this bug changes the requirement to just a recently valid consensus. It's getting tested as I write these words on January 11th. The fix, or something very similar to it, will be merged and backported in the coming days, at which point it's up to the packagers for your OS or your tor-derived software (e.g. Tor Browser) to notice the update and distribute it to you. I would expect Tor Browser to be updated very quickly. Debian will probably take a day or two. Other distros, I have no idea.

If you're watching tor's logs, the current date includes "January" and "2021", and you see the following message, then you have most likely hit the bug.

Tried for 120 seconds to get a connection to [scrubbed]:6697. Giving up. (waiting for rendezvous desc)

The 6697 is not important. The "waiting for rendezvous desc" is important.

Status of the fix making it into Tor

Primary sources for this section: bug #40237.

  • Jan 12th: the fix is merged into [blog post]

Upcoming events:

  • backports to other supported versions of Tor
  • packaging

Fallback dirs getting hit too

On the 11th we notice the fallback dirs are also failing. This is major evidence in my opinion that this is not a purposeful attack on the dirauths. I, and at least two dirauths, think it is most likely a bad custom Tor client implementation that requests directory information too often.

We see the same failing of fallback dirs on the 12th.

This graph shows how the entire network is fielding more directory requests these days. This graph shows more context for where load usually is. The 1.5 Gbit/s the dirauths saw for ~half of 2020 is talked about in this ticket.

An actual attack could disguise itself like this, but if this were an attack, I would expect it to be more consistently effective at preventing consensus generation.

It might be over now

(Last updated 28 Jan 2021)

The 14th saw no missing consensuses. If you had trouble reaching v3 onion services on the 14th, your issue is unrelated to the topic of this blog post.

The 15th saw no missing consensuses.

The 16th probably didn't miss any consensuses (I waited too long to check. Go look in the archive if you care enough).

The 17th saw none missing.

The 18th saw none missing.

So far the 19th saw none missing.



The 28th of January: lots of directory traffic at dirauths again. It is unknown if fallback dirs see it too.


What Tor relays/clients need to be updated?

No relays need to be updated. Tor clients hosting v3 onion services and Tor clients wishing to visit v3 onion services will need to be updated when the fix is released.

How do I update my Tor?

(Last updated 13 Jan 2021)

You don't yet, unless you're willing to compile and use a version of Tor that isn't considered stable yet. If you're willing, then see

Should we temporarily downgrade to v2 while waiting for a fix?

If absolutely necessary, sure. Please keep in mind v2's issues (briefly described below in the glossary) and be aware that "temporary" probably means ~1 week (crossing my fingers). I personally will just suffer and wait for the fix to be released.

Are v3 onion services fundamentally broken?


Is this really major?

Eh ... yes because of the impact, but no because the fix is easy and will be out quickly.

Who was it?

One possibility is people using some 3rd party Tor client called "torpy." See the 5+ messages in this tor-dev@ thread, especially Sebastian and Roger's responses.

Glossary and preemptive rebuttals

Directory authorities / dirauths

There are 9 relays operated by highly trusted individuals that decide the state of the network. They decide what relays are a part of the network and what certain network parameters should be set to.

In a way they are a "single" point of failure and make the Tor network "centralized." Decentralizing their role to 100s, 1000s, or every relay would:

  1. require massive fundamental changes to how Tor works. By itself this probably is not a convincing reason to not do it.

  2. open Tor up to new attacks it currently isn't vulnerable to. This should be a bit more convincing. The keyword to Google for most of them is "Sybil".

Having a "single" high quality root of trust is a valuable property that "decentralize all the things!" people do not generally appreciate enough, in my opinion.

You: This v3 onion fix doesn't actually address the root problem: the dirauths weren't able to communicate and create consensuses.

Yes! You are absolutely right that something about how the dirauths work should change such that they can continue communicating with each other even in the presence of malicious (purposefully malicious or not) traffic! This ticket is one idea and a good place to start your research if I say nothing more and you want to research what is being done yourself. They might also update this ticket.

V3 onion service

The new type of onion service. Names are 56 characters long, like tv54samlti22655ohq3oaswm64cwf7ulp6wzkjcvdla2hagqcu7uokid.onion. V2 onions are 16 characters long, like 3g2upl4pq6kufc4m.onion.

V2 onion services use old crypto and old protocols that are obsolete and dangerous now or will be soon. The code for v2 is messy and the protocol is not extensible. V2 onions are vulnerable to harvesting by malicious HSDirs, and these malicious HSDirs exist today (and are removed as soon as they are detected). Support for v2 onion services will be removed from Tor soon. V3 onions are the future despite the current events.

Fallback directory mirror / fallback dir

Tor clients don't usually directly fetch consensus information from a dirauth anymore. There's too many people using Tor and only 9 dirauths. Instead, a large number of relays that are high quality have opted in to also be hardcoded into Tor source code so clients can usually fetch consensus data from them on first run. After first run and successful connection to Tor, clients get this stuff from their guard instead.


The dirauths vote on what relays are currently in the network and what certain network parameters should be set to. The "average" of their votes become the consensus. They make a consensus every hour and each is valid for three hours. Clients typically fetch a new consensus every two hours.

You can see information from the current consensus here. Recent consensuses are archived here and older ones archived here.

@blog January 27, 2021 - 07:40 • 1 months ago
New Release: Tor Browser 10.0.9
New Release: Tor Browser 10.0.9 sysrqb January 26, 2021

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

This release updates Firefox to 78.7.0esr for desktop and Firefox for Android to 85.1.0. This release includes important security updates to Firefox for Desktop, and similar important security updates to Firefox for Android.

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

  • All Platforms
    • Update NoScript to 11.1.9
  • Windows + OS X + Linux
    • Update Firefox to 78.7.0esr
    • Bug 40249: Remove EOY 2020 Campaign
  • Android
    • Update Fenix to 85.1.0
    • Bug 40137: Remove EOY 2020 Campaign
    • Bug 40165: Update zstd to 1.4.8
    • Bug 40308: Disable network state partitioning until audit
  • Build System
    • All Platforms
      • Update Go to 1.14.14
    • Android
      • Bug 40190: Update toolchain for Fenix 85
      • Bug 40191: Update Fenix and dependencies to 85.0.0-beta1
      • Bug 40193: Build all mobile Rust targets in a single step
      • Bug 40208: Mitigate uniffi non-deterministic code generation
@blog January 26, 2021 - 23:05 • 1 months ago
New Release: Tor Browser 10.5a8
New Release: Tor Browser 10.5a8 sysrqb January 26, 2021

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

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

This release updates Firefox to 78.7.0esr for desktop and Firefox for Android to 85.1.0. Additionally, we update Tor to This release includes important security updates to Firefox for Desktop, and similar important security updates to Firefox for Android.

Note: Default bridges were not working in recent Tor Browser Alpha versions and Tor Browser did not start, as a result. The underlying issue is now fixed and Tor Browser Alpha should be usable again in that configuration. Sorry for the inconvenience.

Note: Tor Browser 10.5 does not support CentOS 6.

The full changelog since Tor Browser 10.5a7 is:

  • All Platforms
    • Update NoScript to 11.1.9
    • Update Tor to
  • Windows + OS X + Linux
    • Update Firefox to 78.7.0esr
    • Bug 40249: Remove EOY 2020 Campaign
    • Bug 40307: Rebase 10.5 patches onto 78.7.0esr
  • Android
    • Update Fenix to 85.1.0
    • Bug 40037: Rebase 10.5 patches onto 70.0.16
    • Bug 40137: Remove EOY 2020 Campaign
    • Bug 40139: Rebase 10.5 patches onto 85.1.0
    • Bug 40305: Rebase 10.5 patches onto 85.0
  • Build System
    • All Platforms
      • Update Go to 1.15.7
      • Bug 33693: Change snowflake and meek dummy address [tor-browser]
    • Android
      • Bug 40208: Mitigate uniffi non-deterministic code generation
    • Linux