July 2024 - anti-censorship-team - lists.torproject.org

Mac app / Safari extension for Snowflake
by David Fifield 02 Oct '25

02 Oct '25

Browsing through some search results, I found: https://apps.apple.com/us/app/torproject-snowflake/id1597501940 (https://web.archive.org/web/20220222083316/https://apps.apple.com/us/app/to…) https://github.com/jayluxferro/snowflake It looks like a repackaging of the Snowflake JavaScript proxy code for Mac and Safari environments. Maybe we could get in touch with the developer and find a way to adopt it into the main repository?

3 2

Microsoft announces shutting down domain fronting attempts in Azure
by Cecylia Bocovich 18 Nov '24

18 Nov '24

It looks like Azure is going to shutdown domain fronting: https://www.microsoft.com/security/blog/2021/03/26/securing-our-approach-to… There isn't a time frame listed in the article, and I haven't gotten any notifications through my Azure account yet. Cecylia

7 9

[support@greenhost.nl: [eclips.is] Planning eclips.is platform 2024 - 2025]
by David Fifield 30 Jul '24

30 Jul '24

FYI, I received this email from eclips.is, where the Snowflake broker is hosted. We currently pay nothing for the service, but it sounds like they are moving to a model where some of the users pay. The closing of the Miami location does not affect us, I believe. ----- Forwarded message from "eclips.is" <support(a)greenhost.nl> ----- Date: Tue, 23 Jul 2024 09:53:42 +0000 From: "eclips.is" <support(a)greenhost.nl> To: david(a)bamsoftware.com Subject: [eclips.is] Planning eclips.is platform 2024 - 2025 Hello Tor pluggable transports, A few months ago, we asked you to fill out a survey on your needs, use, and financial options regarding the Eclips.is project. Taking those answers into account, we are working towards a sustainable structure for Eclips.is. While we are working on a detailed plan, we already wanted to provide you with some information about the overall strategy. Financially, we will be moving towards a hybrid model where people contribute to the maintenance of the platform based on their budgetary options. This way, we trust we can still offer the platform free of charge to those organizations that need it most and/or do not have budget available, while stronger shoulders can contribute. Once the details and requirements are clear, we will share those with you. In addition to generating some funds as described above, we also want to optimize maintenance processes and running costs, so we can serve as many organizations as possible for the lowest costs. We will be doing this in two ways: - We will integrate the current Eclips.is platform into our Greenhost platform. This makes it easier to maintain the platform and makes it possible to offer (hybrid) payment models. - We will, unfortunately, close down the Miami location. The IPs and VPSs will be migrated to Amsterdam. This migration will begin in October 2024, and of course, we will try to limit the impact as much as possible. eclips.is users who have machines hosted at that location will receive additional information on the migration process, such as an exact time frame, in the months and weeks leading up to this migration. Greenhost is committed to the platform and has secured resources for eclips.is until the end of 2025. Throughout this reorganization, we will be working closely with the Open Technology Foundation (OTF) for a longer sustainability plan to ensure we can continue supporting data privacy and the internet freedom community. If you have any questions regarding this reorganization, please let us know! The Greenhost/eclips.is Team Questions? Contact us on support(a)eclips.is ----- End forwarded message -----

2 1

snowflake blocking experiment
by Roger Dingledine 25 Jul '24

25 Jul '24

At the Tor community day in Lisbon, Gus did a talk on Snowflake, and included what I found to be a controversial statement: that Snowflake is inherently more enumeration-resistant than approaches like obfs4. I thought "that can't be true, because the broker just gives out snowflakes to anyone, as many as you like!" so I decided to do a blocking test. The blocking approach was simple and conservative: I instrumented my Snowflake in Tor Browser to tell me each offer as it learned it, and I added each address as a local firewall block rule as it appeared. You could imagine that a national firewall might take this approach. It is intentionally super slow and subtle (it looks like just one user having connectivity problems), so no rate limiting approaches at the broker could impact it without harming many real users. If I wanted to scale it I would run n of them in parallel, so in that sense my results are a best case scenario for users. I tracked a rolling "what percentage of the last 100 offers were already blocked" metric. After some hours, my user behind an unrestricted nat stayed around 30% to 50% already blocked. Whereas if I'm behind a restricted nat, it went up to 80% to 90% already blocked after some hours. Initial conclusions: (A) This is another way for measuring Snowflake churn, to go with the analysis that Shel did in the Snowflake paper: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… i.e. we can see / estimate the churn from a second angle to confirm those results. (B) Cecylia pointed out that because of how I structured the experiment, I have real-world timing numbers too: I know how long it will take for a Tor Browser using snowflake in this situation to find a fresh proxy. (C) The pool for users behind unrestricted nat is quite robust, whereas the pool for users behind restricted nat is much smaller. We knew this in theory but here it is in practice. (D) We have a future roadmap item of increasing enumeration-resistance at the broker. One way to achieve this goal would be to find a way to use more of our restricted-nat volunteer pool! (E) A little glimmer of hope: even my user behind restricted nat usually got a fresh proxy after ten or twenty tries. I am curious how that number looks during an extended censorship run (i.e. days) though. (F) An interesting twist I realized during the experiment: Snowflake is super-active-probing-resistant. That is, one of the tasks a censor needs to do is expire entries in its blocklist after a while. For obfs4 bridges, the censor can see if something is still listening on that port, and refresh the blocklist entry if so. But for Snowflake, the way you learn if a proxy is still running is that the broker tells you about it again. It seems there is a tension between leaving proxies on the blocklist for too long (producing collateral damage), vs keeping enough of them blocked to impact users. (G) Nick Hopper pointed out the fun research question: is there some other way to check if a Snowflake proxy is still running? For example, examining its router state for evidence that it is doing Snowflake related activity, perhaps via portscanning or TCP or IP side channels? I have the blocking/analysis scripts still, as well as the output from the first experiments. Maybe I will do a more thorough experiment in some future hackweek. --Roger

1 0