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

PDF of "Bridging Barriers" for reading group
by David Fifield 01 Aug '24

01 Aug '24

The authors sent me a copy of the paper scheduled for the 2024-08-22 reading group. Cf. https://lists.torproject.org/pipermail/tor-project/2024-August/003842.html https://meetbot.debian.net/tor-meeting/2024/tor-meeting.2024-08-01-16.00.ht…

1 0

[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

Is there any way to bypass Tor block on OpenWRT
by Eli Eli 24 Apr '24

24 Apr '24

Hi!I have issue to add moats to my OpenWRT Tor.Can anyone help me with this?Here is my main post on GL-Inet forum:forum[.]gl-inet[.]com/t/how-to-bypass-tor-block-on-mudi/41336

2 1

Ansible for Tor Network Webtunnel Bridges
by Jacobo Nájera 19 Apr '24

19 Apr '24

Hi, Share this Ansible role for Webtunnel, with which you can install, configure, and operate Tor network Webtunnel bridges. Currently, it supports installing bridges on Debian, with support for other operating systems coming soon. Repository with the Ansible role for Webtunnel https://github.com/nvjacobo/webtunnel In the Ansible Galaxy repository https://galaxy.ansible.com/nvjacobo/webtunnel A small guide to use the role https://acuare.la/en/ansible-webtunnel-bridges-tor-network/ Feedback are welcome! Thanks, Jacobo

1 0

"Snowflake Anonymous Network Traffic Identification", November 2023
by David Fifield 19 Apr '24

19 Apr '24

Snowflake Anonymous Network Traffic Identification Yuying Wang, Guilong Yang, Dawei Xu, Cheng Dai, Tianxin Chen, Yunfan Yang https://link.springer.com/chapter/10.1007/978-981-99-9247-8_40 This paper tries to detect Snowflake by focusing on the DTLS transfer. Unlike the F-ACCUMUL paper (https://www.mdpi.com/2076-3417/13/1/622) however, it doesn't use DTLS handshake features, but rather traffic analysis features such as packet lengths and interarrival times. Their classifier is a multilayer perceptron, though they also try SVM, random forest, and naive Bayes. The experiment is a closed world consisting of Snowflake, Facebook Messenger, Google Hangouts, and Discord. They don't evaluate realistic base rates: the most imbalanced evaluation they try is 40:1 (Figure 5). In short, it doesn't look like there is much to learn from this paper. > Traffic identification is a dynamic process, and as we identify > traffic features, Snowflake developers may modify these features to > render our model ineffective. This could lead to an ongoing > cat-and-mouse situation. It is necessary to continually collect > traffic data to maintain a high level of accuracy. In the future, we > hope to automate this process to adapt to updates and changes in > Snowflake versions. Unusually, the authors have publised the Docker image they used to generate training and test data: https://hub.docker.com/layers/xinbigworld/ubuntu/1.2/images/sha256-3213fded…

1 0

Graphs of Snowflake bridge bandwidth since March 2024 domain fronting changes
by David Fifield 15 Mar '24

15 Mar '24

Here are some graphs of the bandwidth at the 2 Snowflake bridges since the end of domain fronting on Fastly on 2024-03-01 (https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/135) You can compare this to similar analysis made in October 2023, after a similar situation when the default front domain changed from Fastly to Cloudflare: https://lists.torproject.org/pipermail/anti-censorship-team/2023-October/00… 1. As before, snowflake-02 was relatively harder hit than snowflake-01. But this time it didn't get nearly as close to zero. However, there's an evident secondary step down on 2024-03-07, which may or may not be related. 2. Also as before, snowflake-02 suddenly (within 10 minutes) recovered a large amount of bandwidth about 14 days later, at 2024-03-15 10:45. A similar sudden increase is visible with snowflake-01 at the same time. Last October, it (if it is indeed the same effect) happened at about 11:45, one hour later UTC.

1 0

Snowflake and Fastly
by Michael Rogers 04 Mar '24

04 Mar '24

Hi all, While updating Briar's bridge config I noticed that Moat is still returning a Fastly URL among its snowflake bridge lines for some countries. Are these lines still working (temporarily?) or should I substitute the CDN77 front? Thanks, Michael

1 0

Re: [anti-censorship-team] Draft for Snowflake 2023-in-review post
by David Fifield 24 Jan '24

24 Jan '24

On Mon, Jan 22, 2024 at 04:33:53PM +0100, ERIK NORDBERG wrote: > This is a great report. > I would like to post it as it is as ’2023 year in review' on https:// > opencollective.com/censorship-circumvention/projects/snowflake-daily-operat… > /updates. > No need to strip it to cover only snowflake-01, as I see it. > OK? Yes, that's OK. Here's the slightly edited text I posted. --- This is a summary of usage of the [Snowflake](https://snowflake.torproject.org/) pluggable transport in 2023. For the previous year's summary, see the [Snowflake 2022 year in review](https://opencollective.com/censorship-circumvention/projects/snowfl…. The primary Snowflake bridge, called snowflake-01, is supported by donations. In 2023, the [Snowflake Daily Operations team](https://opencollective.com/censorship-circumvention/projects/snowflak… paid about [€4,820](https://opencollective.com/censorship-circumvention/projects/snowflake-daily-operations/expenses?collectiveType=projects&parentCollectiveSlug=censorship-circumvention&collectiveSlug=snowflake-daily-operations&period=2023-01-01T00%3A00%3A00.000Z%E2%86%922023-12-31T23%3A59%3A59.999Z%7EUTC) in hosting expenses to keep the bridge running—with most of that going for bandwidth. In 2024, in addition to paying for bandwidth, we would like to buy new hardware for the bridge, which will enable it to support more users at the busiest times of day. You can help by [donating to support the bridge](https://opencollective.com/censorship-circumvention/projects/snowfl…. Let's start by looking at the daily users and bandwidth. Tor user graphs show an estimate of the [average number of simultaneously connected users](https://metrics.torproject.org/reproducible-metrics.html#users) (not unique IP addresses). For instance, if the line passes through 40,000 on a particular day, it means there were, on average, 40,000 users connected to Snowflake at any given time during that day. The bandwidth graph shows the total amount of Tor traffic transferred per day. As of January 1, 2024, Snowflake supported an average of about 40,000 simultaneous users and transferred about 35 TB of circumvention traffic per day. While the number of users is lower than it was at the beginning of the year, bandwidth is up by more than 50%. [snowflake-userstats-bridge-transport-2023.png] [snowflake-bandwidth-2023.png] These are some of the events that affected Snowflake usage in 2023: * Between 2023-01-16 and 2023-01-24, and intermittently thereafter, domain fronting rendezvous was [blocked in parts of Iran](https://bugs.torproject.org/tpo/anti-censorship/team/115). As more Snowflake users are in Iran than in any other country, this resulted in an observable decrease in the number of users. * On 2023-03-13, the Tor anti-censorship team [fixed a security bug](https://forum.torproject.org/t/security-advisory-cross-user-tls-traffi… that had also negatively affected performance since September 2022. This greatly improved bandwidth for all users. * The big drop in users on 2023-09-20 was not caused by a censor. Rather, it was an [unexpected change](https://forum.torproject.org/t/problems-with-snowflake-since-2023-0… in the infrastructure used by Snowflake for rendezvous. Mitigating the problem required new software releases. Before 2023, we had used just one, centralized Snowflake bridge. Last year we started using [a second bridge](https://bugs.torproject.org/tpo/anti-censorship/pluggable-transport… in order to scale to more users. Here are the same user and bandwidth graphs, but with the snowflake-01 and snowflake-02 bridges shown separately. Strangely, the domain front change of 2023-09-20 [affected the two bridges differently](https://lists.torproject.org/pipermail/anti-censorship-team/20…. [snowflake-userstats-bridge-transport-multi-2023.png] [snowflake-bandwidth-multi-2023.png] We can also break down users by country. The largest contingent of Snowflake users are in Iran, which has been the case since [the Mahsa Amini protests in 2022](https://ooni.org/post/2022-iran-blocks-social-media-mahsa-amini-prote…. The graph shows also a large number of users apparently from the United States, but we believe that may be partly the result of geolocation errors, and many of them are [actually from Iran](https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/…. After Iran, the countries with the most Snowflake users are Russia and China. On 2023-04-10 the team [fixed a bug](https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/s… in the browser proxy that caused some users to be wrongly attributed to the unknown "??" country code. The cause of the per-country user count estimates becoming less precise between October and December was a [user-counting bug](https://bugs.torproject.org/tpo/core/tor/40871) in Tor that existed from version 0.4.8.4 until 0.4.8.10. [snowflake-top-countries-2023.png]

1 0

Snowflake bridge operations
by Linus Nordberg 22 Jan '24

22 Jan '24

Hi, I started asking questions in #tor-anticensorship about how traffic can be directed towards certain snowflake bridges. Moving my questions here to reach more/other people. --8<---------------cut here---------------start------------->8--- Hey all. In trying to make a 2024 budget for the [Snowflake Operations][] project operating snowflake-01.tpn I need a better understanding of how we direct traffic to the running bridges. Both what potential challenges there are to do it and what the policy for it looks like. The background is that snowflake-01 is close to going full due to CPU consumption. I haven't spotted any flat lines yet but have seen momentary CPU utilisation of 98% a couple of times. Here are two of the questions I'm looking for an answer to. 1. If we get another server, similar to snowflake-01 wrt performance, will it be useful to the network? Ie will it offload snowflake-01? 2. If we do **not** get another server and snowflake-01 goes full, will users have a bad network experience as a result of this? Can traffic be moved to snowflake-02? [Snowflake Operations]: https://opencollective.com/censorship-circumvention/projects/snowflake-dail… --8<---------------cut here---------------end--------------->8---

3 3