anti-censorship-team August 2024

anti-censorship-team@lists.torproject.org

4 participants
5 discussions

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

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

2024

2023

2022

2021

2020

2019

anti-censorship-team August 2024