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

Rust port of extor-static-cookie
by David Fifield 01 Mar '22

01 Mar '22

As an experiment to wring more performance from the snowflake bridge, I started a rough port of the extor-static-cookie shim to Rust. It's not in what I would call a production-ready state with regard to documentation and tests—I wanted to hack something together quickly in order to decide whether it's worth spending more time on. I am also pretty new to Rust async programming. As a side consideration, I wanted to get an idea of what a pluggable transports library for Rust might look like. https://gitlab.torproject.org/dcf/extor-static-cookie/-/tree/rust Currently commit 559fb5e292b45d82464bdaf978c6e1783c796e3d I have the Rust implementation running now (since 2022-02-27 03:00) under the flakey4 instance. The other three instances are running the Go implementation. It's too early to say whether it reduces CPU usage; an hour after being restarted, the flakey4 instance is still catching up to the traffic of the other instances. But it looks like it's stable and functional, at least.

2 2

bridgedb+rdsys test setup
by meskio 28 Feb '22

28 Feb '22

For the last few months I've being working on integrating rdsys with bridgedb, so bridges are managed by rdsys and bridgedb only does the distribution (https, moat and email)[0]. There will not be any visible changes, but all the insides are different. Thanks to the TPA work now we have a testing setup of the new setup to test it. If you want to test it I'll be happy to hear if you find any issues with it. As this is distributing real bridges only people with accounts in TPO LDAP has access to it. How to access the different distributors: * email. Just write an email to bridges-test(a)torproject.org from your @torproject.org email, and should get a reply with bridges. * https. The web interface is available at https://bridges-test.torproject.org, but only reachable from people.torproject.org. You can make a ssh proxy: $ ssh -D 9999 people.torproject.org and configure your browser to use a SOCKS proxy at localhost with port 9999. * moat. This is reachable the same way that https only from people.torproject.org. Is a bit more complicated to test, but I will stress test it myself :) I wrote I simple script to do the moat captcha request and solution: https://gitlab.torproject.org/-/snippets/127 It's run like: $ MOAT_URL="https://bridges-test.torproject.org/moat" CURL_OPTIONS="--socks5 localhost:9999" ./test-moat Thank you. [0] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/12 -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

2 5

Surge in Snowflake client polls
by Cecylia Bocovich 28 Feb '22

28 Feb '22

While looking at the snowflake broker metrics for clues about the sudden drops in known proxy NAT types[0], I noticed that the broker metrics show a very large spike in client polls over the last day. I've attached a few graphs that show this, which probably won't have showed up in tor relay metrics yet. One of the graphs is the usage of proxy capacity, which shows a rise in the number of client polls and a large drop in idle proxies. The other graph shows something similar, but for the pool of proxies available to clients with restrictive NATs. Here we see that the overwhelming majority of clients are being denied because all of the proxies are used. To some extent, we expect this and have seen it in the past, particularly for the pool of proxies for clients with restrictive NATs. The pattern follows a natural day-long period, and the number of denied clients never gets so high that a client won't get a proxy after 2-3 tries. However, these attached graphs go back 48 hours and show how much bigger the spike in clients is over the last day. At the peak of the spike, there were 5x as many clients requesting snowflake proxies from the restrictive pool as we had proxies to match. Perhaps this is a good time to push to get more proxies? It seems we could use proxies for both restrictive and unrestrictive NATs at this point. Cecylia [0] https://lists.torproject.org/pipermail/anti-censorship-alerts/2022-February…

1 1

Snowflake bridge outage, 2022-02-18
by David Fifield 24 Feb '22

24 Feb '22

On 2022-02-18 the Snowflake bridge was offline between about 14:02:05 and 15:26:38. I was alerted to the outage by Shelikhoo. The cause of the outage is unknown. There had been some kind of kernel crash (see first attached file for what was visible on the console), which required me to restart the VPS externally. After I restarted it, everything came back as normal. I asked Greenhost support if they knew of anything that might have happened in the data center to cause the problem, and they did not. I asked about using a management API to automatically restart the server if it happens again, but they did not have specific guidance on that. Resource graphs show that the CPU was still active during the outage, but the network usage was quiet.

1 0

Mac app / Safari extension for Snowflake
by David Fifield 22 Feb '22

22 Feb '22

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?

2 1

Snowflake bridge VPS cost estimates
by David Fifield 17 Feb '22

17 Feb '22

I haven't yet got a lead on finding a stronger server for the Snowflake bridge. I did some rough estimates: the cost of a VPS for what we need is about $250/month, and bandwidth will probably be about another $1000/month. The minimum hardware specs that would make moving the server worthwhile is 16 CPUs and 32 GB RAM. To get an idea of the range of pricing: * Linode 32 GB: $240/month https://www.linode.com/pricing/#compute-dedicated https://web.archive.org/web/20220207055603/https://www.linode.com/pricing/#… * Azure F16s v2: $292/month (1 year reserved) https://azure.microsoft.com/en-us/pricing/details/virtual-machines/linux/ https://web.archive.org/web/20220215193358/https://azure.microsoft.com/en-u… * Hetzner CCX42: €166/month = $189/month https://www.hetzner.com/cloud https://web.archive.org/web/20220214145505/https://www.hetzner.com/cloud The estimate of $1000/month for bandwidth comes from a typical cost of $0.01/GB = $10/TB, and the fact that during the 6 days the staging bridge was active, it averaged about 2.9 TB/day sent (and was rising). https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…

2 2

obfs4proxy-0.0.12 (2021-12-31) fixes the Elligator2 bug
by David Fifield 17 Jan '22

17 Jan '22

The upstream obfs4 repository has a fix to the Elligator2 public key representative leak (https://github.com/agl/ed25519/issues/27). https://gitlab.com/yawning/obfs4/-/commit/393aca86cc3b1a5263018c10f87ece09a… All releases prior to this commit are trivially distinguishable with simple math, so upgrading is strongly recommended. The upgrade is fully backward-compatible with existing implementations, however the non-upgraded side will emit traffic that is trivially distinguishable from random. The file internal/README.md elaborates: All existing versions prior to the migration to the new code (anything that uses agl's code) are fatally broken, and trivial to distinguish via some simple math. For more details see Loup Vaillant's writings on the subject. Any bugs in the implementation are mine, and not his. Representatives created by this implementation will correctly be decoded by existing implementations. Public keys created by this implementation be it via the modified scalar basepoint multiply or via decoding a representative will be somewhat non-standard, but will interoperate with a standard X25519 scalar-multiply. As the obfs4 handshake does not include the decoded representative in any of it's authenticated handshake digest calculations, this change is fully-backward compatible (though the non-upgraded side of the connection will still be trivially distinguishable from random).

2 4

Meeting to set up staging snowflake bridge, 2022-01-11 16:00 UTC
by David Fifield 10 Jan '22

10 Jan '22

We'll meet tomorrow, 2022-01-11 at 16:00 to cooperatively set up a staging Snowflake bridge. Let's meet in #tor-dev and we can move from there if needed. I am anticipating spending 2 hours or less on this. https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… Here is a pad with an agenda and a place to draft an installation guide. https://pad.riseup.net/p/pvKoxaIcejfiIbvVAV7j If you have SSH and sudo access on the existing Snowflake bridge, you should already have the same on the staging server. I am thinking that we can share a screen session and work through the installation steps, keeping notes in the pad.

1 0

Kazakhstan shutdown: bridges on port 3785 are reported to work
by David Fifield 09 Jan '22

09 Jan '22

There has been a near-total Internet shutdown in Kazakhstan since 2022-01-05, with only a few hours of partial connectivity per day. From correspondence with some of the people affected, it appears that, for whatever reason, proxies on TCP port 3785 are accessible during the shutdown, at least on Kaz Telecom, the largest ISP. I set up an obfs4 bridge on port 3785 and a user reported that it was reachable. It might be a good idea to push to have a few bridges that run on port 3785, at least for the front desk to hand out? httpe://ntc.party/t/network-shutdown-all-around-kazakhstan/1601 https://github.com/net4people/bbs/issues/99 https://ntc.party/t/network-shutdown-all-around-kazakhstan/1601/14 > SOCKS5 proxy 3785 port works fine. Not sure why, VoIP using skype and > other services works as well, so I guess 3785 may be used for VoIP > > in general, it’s easy to configure in telegram, but if clients are > able to configure proxy on their OS(for example using proxifyer) https > and all other traffic works as well. > > This has been tested in at least 3 regions. https://ntc.party/t/network-shutdown-all-around-kazakhstan/1601/16 > > I am not familiar with that one either. nmap-services calls it > > bfd-echo “BFD Echo Protocol”. RFC 5881 says it is a UDP protocol: > > Yeah, if it’s not VoIP I have no idea why it works. I guess people > found it out by brute-forcing different ports https://ntc.party/t/network-shutdown-all-around-kazakhstan/1601/17 > Here is an obfs4 bridge on port 3785 (IPv4 and IPv6) to try in Tor > Browser: https://ntc.party/t/network-shutdown-all-around-kazakhstan/1601/19 > The IPv4 obfs4 bridge is working!

1 0

Insufficiently many pregenerated BridgeDB captchas?
by David Fifield 15 Dec '21

15 Dec '21

For the Moat and HTTPS distributors, BridgeDB uses a cache of pregenerated captcha images. It does not generate a fresh captcha for every challenge. https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/blob/eeca27703… > ...The second method uses a local cache of pre-made CAPTCHAs, > created by scripting Gimp using gimp-captcha. The latter > cannot easily be run on headless server, unfortunately, > because Gimp requires an X server to be installed. https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/blob/eeca27703… imageFilename = random.SystemRandom().choice(os.listdir(self.cacheDir)) imagePath = os.path.join(self.cacheDir, imageFilename) with open(imagePath, 'rb') as imageFile: self.image = imageFile.read() It may be that there are simply too few pregenerated captcha images. If there are N total, and an adversary invests effort to solve n of them, then the adversary will get a captcha it knows in n / N fraction of later bridge queries, until the cache of pregenerated images is regenerated. I downloaded 1000 captcha images from the Moat API and hashed them: for a in $(seq 1 1000); do curl -s -x socks5h://127.0.0.1:9050/ https://bridges.torproject.org/moat/fetch -H 'Content-type: application/vnd.api+json' --data-raw '{"data": [{"version": "0.1.0", "type": "client-transports"}]}' | jq '.data[0].image' | sha256sum; done | tee bridgedb.hashes Out of 1000 images drawn randomly with replacement, 916 appeared 1 time 39 appeared 2 times 2 appeared 3 times We can use a capture–recapture technique to estimate the total population size. https://en.wikipedia.org/wiki/Mark_and_recapture#Lincoln%E2%80%93Petersen_e… Divide the 1000 images into 2 equal halves, and count the unique images in each half: n = 488, k = 492. The number of images in the second half that were already seen in the first half is K = 23. The estimate for N = n*K/k = 488*492/23 = 10439, so I guess the captcha cache dir on the BridgeDB server holds only about 10000 images. >>> pop = list(open("bridgedb.hashes")) >>> s1, s2 = set(pop[:len(pop)//2]), set(pop[len(pop)//2:]) >>> len(s1) 488 >>> len(s2) 492 >>> len(s1.intersection(s2)) 23 >>> len(s1)*len(s2)/len(s1.intersection(s2)) 10438.95652173913 It would be best to generate a fresh captcha image for each challenge, but if that's not possible, we should increase the number of cached images or regnerate the cache periodically.

3 2

2025

2024

2023

2022

2021

2020

2019

anti-censorship-team