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

Significant ?? country users of snowflake-01 in August 2024
by David Fifield 06 Sep '24

06 Sep '24

Making some graphs for the August 2024 Snowflake bridge report, there are a couple of weird things to comment on. On August 22–23, there was a drop in users across both bridges that later almost evened out. (See first attachment.) It affected both bridges. >From August 16–31, the ?? country broke into the top 5 countries by user count, on the snowflake-01 bridge only. (See third attachment.) Because the country code comes from the proxy, which reports the remote IP address of the client, a country code of ?? means that either the proxy did not report an IP address (no client_ip WebSocket URL parameter), or the IP address was not found in a geolocation lookup. Here's a past case where a bug in the WebExtension was resulting in ?? countries: https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… The snowflake server logs daily the fraction N/D of connections that had client_ip set. In the case before, N decreased while D remained constant. In this case, it looks like N is remaining constant while D is greatly increasing. See in the listing below how N/D suddenly drops from 99% to 41% on 2024-08-13. In the last couple of days, ⅔ to ¾ of connections have been missing the client_ip parameter. The client_ip-less connections must not represent very many user-hours, otherwise they would completely dominate the user graphs. Did something happen on 2024-08-13? Is this a new source of proxies with an implementation bug? Some kind of attack? (Against the bridge?) $ grep 'connections had client_ip$' /var/log/snowflake-server/snowflake-server.log | perl -ane '$F[7] =~ m#^(.*)/(.*)$#; printf("%s %s %8d/%-8d %6.2f%%\n", $F[0], $F[1], $1, $2, 100 * ($2 == 0 ? 0.0 : $1/$2));' 2024/08/06 08:57:22 463234/464597 99.71% 2024/08/07 08:57:22 462398/463581 99.74% 2024/08/08 08:57:22 453003/454165 99.74% 2024/08/09 08:57:22 450344/451707 99.70% 2024/08/10 08:57:22 450057/452228 99.52% 2024/08/11 08:57:22 449782/452296 99.44% 2024/08/12 08:57:22 452387/475006 95.24% 2024/08/13 08:57:22 450993/1089806 41.38% 2024/08/14 08:57:22 455701/828402 55.01% 2024/08/15 08:57:22 449159/886577 50.66% 2024/08/16 08:57:22 430698/1061690 40.57% 2024/08/17 08:57:22 426891/1240861 34.40% 2024/08/18 08:57:22 428010/1139078 37.58% 2024/08/19 08:57:22 425667/1363289 31.22% 2024/08/20 08:57:22 427042/1181316 36.15% 2024/08/21 08:57:22 422347/1407363 30.01% 2024/08/22 08:57:22 418760/1437024 29.14% 2024/08/23 08:57:22 271142/1217897 22.26% 2024/08/24 08:57:22 353388/1291375 27.37% 2024/08/25 08:57:22 366323/1117172 32.79% 2024/08/26 08:57:22 382452/1107561 34.53% 2024/08/27 08:57:22 416759/1451520 28.71% 2024/08/28 08:57:22 413329/1445703 28.59% 2024/08/29 08:57:22 403754/1490629 27.09% 2024/08/30 08:57:22 388147/1490993 26.03% 2024/08/31 08:57:22 395311/1377168 28.70% 2024/09/01 08:57:22 389361/1344726 28.95% 2024/09/02 08:57:22 377702/1169902 32.28% 2024/09/03 08:57:22 369956/1272026 29.08% 2024/09/04 08:57:22 368266/1330355 27.68% 2024/09/05 08:57:22 371429/1260571 29.47%

2 3

obfs4/lyrebird terminology
by David Fifield 22 Aug '24

22 Aug '24

A coupld of forthcoming papers are using "Lyrebird" as if it were the name of a protocol, a synonym for obfs4: https://arxiv.org/abs/2405.13310 > Obfs4/Lyrebird is based on Scramblesuit [56]. https://eprint.iacr.org/2024/1086 > The obfs4/lyrebird protocol, specified in [60], is separated into two > distinct phases: This, to me, seems like an incorrect use of terminology. I am planning to tell the authors so. But I just want to check that my understanding matches the consensus opinion, which I would summarize thus: There is no such thing as a "lyrebird" protocol. Lyrebird is a program that implements several protocols, including obfs3, obfs4, and meek. Lyrebird is a fork of obfs4proxy, which likewise is a program, not a protocol. Just as there is no "lyrebird" protocol, there is no "obfs4proxy" protocol; these are names of programs that both happen to implement an identical protocol, which protocol is called obfs4. Do you agree? Tor renaming its fork of obfs4proxy Lyrebird was an effort to reduce confusion. I worry that we will have years of confusion to deal with if the mistaken assumption lyrebird ≈ obfs4 (rather than lyrebird ≈ obfs4proxy) gets consecrated in print.

2 2

covertDTLS: reducing distinguishability of DTLS for usage in Snowflake
by Theodor Midtlien 14 Aug '24

14 Aug '24

Hi! I have talked with some of you in the IRC meetings this year, but I have not updated the mailing list on my work. A little over a month ago I completed my Master's thesis on "Reducing distinguishability of DTLS for usage in Snowflake", at the Norwegian University of Science (NTNU) in the Department of Information Security and Communication Technology, supervised by David Palma. The thesis can be found on my website: https://theodorsm.net/thesis Here is a trimmed abstract: " [...] We have seen that censors have been able to do so [blocking Snowflake] by fingerprinting the DTLS implementation that is produced by the Pion library used by Snowflake. The aim of this thesis is to reduce the distinguisability of said DTLS library. We developed a tool named, dfind [1] for analyzing and finding passive field-based fingerprints of DTLS. This tool was validated using a data set with known fingerprints, and found that the extensions field was especially vulnerable for identification. To combat such fingerprints, we implemented covertDTLS [2], a Go library inspired by uTLS. Our module extends the Pion DTLS library with handshake hooking to offer mimicry and randomization features. To ensure that mimicking remains up-to-date, we developed a novel continuous delivery workflow for generating fresh DTLS-WebRTC handshakes from popular browsers. Using covertDTLS with Snowflake resulted in us not being able to find any fingerprints." [1]: https://github.com/theodorsm/dfind [2]: https://github.com/theodorsm/covert-dtls I have only tested covertDTLS in a messy fork of Snowflake, which had promising results. I am currently working on upgrading the Pion DTLS and WebRTC version used by Snowflake to the most recent version to integrate covertDTLS properly. In addition, I plan to condense my thesis into a paper, thus making the work more accessible. I would greatly appreciate any feedback on the thesis so that I can address those in the paper. I am also open to collaborating on the paper, feel free to reach out if you have some ideas to be explored. Cheers, Theodor Signebøen Midtlien

1 0

Fwd: Clear, 10min_cpu_usage (was warning for 5 hours and 32 minutes), on snowflake-01
by Linus Nordberg 04 Aug '24

04 Aug '24

Hi, snowflake-01 has lately been seeing more traffic than usual and yesterday was really odd. Since the beginning of July this year CPU utilisation has usually been exceeding 85% for between one and two hours, ending about midnight CEST. Yesterday we saw that for five and a half hours ending around 18:00 CEST. Any idea why this is happening? I did see something about snowflake-02 moving somewhere. Can this be related? Is the move done? How did it go? 2 Aug 2024 18:05:53 netdata(a)snowflake-01.torproject.net: snowflake-01 recovered 10min cpu usage (was warning for 5 hours and 32 minutes) average CPU utilization over the last 10 minutes (excluding iowait, nice and steal) (was warning for 5 hours and 32 minutes) Chart : system.cpu Family : cpu Severity: Recovered from WARNING URL : https://api.netdata.cloud/alarms/redirect?agentId=47d61784-c899-11ec-b119-3… Source : 4(a)/usr/lib/netdata/conf.d/health.d/cpu.conf Date : 2024-08-02T15:50:50+0000 Notification generated on snowflake-01 Evaluated Expression : $this > (($status >= $WARNING) ? (75) : (85)) Expression Variables : [ $this = 74.9016704 ] [ $status = 1 ] [ $WARNING = 3 ] The host has 0 WARNING and 0 CRITICAL alarm(s) raised.

2 2

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

2025

2024

2023

2022

2021

2020

2019

anti-censorship-team