Anti-censorship team report: July 2020

by phw | August 10, 2020

Tor's anti-censorship team writes monthly reports to keep the world updated on its progress. This blog post summarizes the anti-censorship work we got done in July 2020. Let us know if you have any questions or feedback!

Snowflake

BridgeDB

Miscellaneous

Tags
anti-censorship
monthly status
Anonymous

Anonymous (not verified) said:

August 10, 2020

Permalink

caching*

Speaking of censorship. Where are all the new comments on the other posts at? Been 2 weeks. Other than that, great work, though I feel dissociated.

Anonymous

Anonymous (not verified) said:

August 11, 2020

Permalink

Thanks for posting this! Hope you keep updating us about anti-censorship team's progress.

Some questions about snowflake: Does the broker still hand out proxy-go instances more than the WebExt ones? I feel like snowflake got way too slow in the last months, I don't know if I mostly get WebExt ones or proxy-go instances but it seems that whenever I connect to a snowflake my connection to one snowflake gets cut off way too quickly with some while for others it stays for a long time (and I'm not from a censored country AFAICT).

> Added more STUN servers to default configuration in Tor Browser.

Can I just go and edit my torrc to this new one or I must have the new `snowflake-proxy`? Looking at the code I believe one must choose a single random one if one doesn't have the new `snowflake-proxy`.

> This will drastically improve performance for Snowflake clients behind restrictive NATs.

Very good news, looking forward to testing it! When's the next Tor Browser alpha coming with the new `snowflake-proxy`?

This change will be automatically available in the next Tor Browser alpha release (which should be next week for desktop alphas, but we're unsure about mobile). In the meantime, you can manually edit your torrc file. See here for the changes we made to the snowflake configuration: https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merg…

> Does the broker still hand out proxy-go instances more than the WebExt ones? I feel like snowflake got way too slow in the last months, I don't know if I mostly get WebExt ones or proxy-go instances but it seems that whenever I connect to a snowflake my connection to one snowflake gets cut off way too quickly with some while for others it stays for a long time (and I'm not from a censored country AFAICT).

Thanks for the feedback! It does still hand out proxy-go instances more frequently. It might've gotten slower because we now have a large influx of webextension proxies. We do have some ongoing work to improve performance next on our roadmap (like https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/…).

Are any other updates failing? Are the updates being downloaded but not installed? Have you checked your configuration of apt and the fingerprint of your copy of the repository's key? Have you opened the repository in a browser and checked if the repository's files are correct? The most recent instructions for configuring apt are here: https://support.torproject.org/apt/

The most recent packages for armhf are listed in the Packages file: https://deb.torproject.org/torproject.org/dists/buster/main/binary-armh… As of today, it lists tor version 0.4.2.7-1~d10.buster+1, and that version's deb file for armhf tor_0.4.2.7-1~d10.buster+1_armhf.deb exists in this directory: https://deb.torproject.org/torproject.org/pool/main/t/tor/

It is possible for you to do the steps to update without apt, starting by exporting your copy of the key from apt-key into GPG to verify the Release file's signature in this directory: https://deb.torproject.org/torproject.org/dists/buster/

Anonymous

Anonymous (not verified) said:

August 12, 2020

Permalink

I tried to post a question about GFC changes in another thread but I think it was censored.

My question is: it seems CN recently changed GFC to ban outright a later version of SSL (or TLS?). This occurred a few weeks before a DEF CON talk showing how that version can be used to deploy a new form of domain fronting, which sounds (to my inexpert ear) like it might be very useful in protecting and growing the Tor network. Do you know whether CN watchers think the change to GFC was intended as a stopgap measure to thwart the new version of domain fronting?

Are you referring to the blocking of ESNI?
https://geneva.cs.umd.edu/posts/china-censors-esni/esni/

ESNI is a useful privacy feature of TLS 1.3. Unlike prior TLS versions, it protects the hostname of the website you're connecting to. For Internet censors, this is bad news because ESNI significantly reduces the visibility that censors have in your communication.

Anonymous

choikepurun (not verified) said:

August 17, 2020

Permalink

I'm having problems with the browser Tor, to enter a twitter account and it temporarily blocks me, ensuring that I'm robot. It ask me to do a google captcha over and over again. How can I solve this problem ?

Ask questions about Tor Browser in the most recent post about Tor Browser. This post is not about Tor Browser, but the ones in the following link are. At the time of writing this, the latest standard release (not alpha/development) is 9.5.3.
https://blog.torproject.org/category/tags/tbb

Some answers to your question may be found in Support linked at the top of the purple pages of torproject.org.

When a site blocks you, you could also try to create a "New Tor Circuit for this Site": Is there a way to change the IP address that Tor Browser assigns me for a particular site?

Personally, I've quit services that reject Tor. A good alternative to Twitter is Mastodon, an open-source decentralized/federated network of microblog servers on the fediverse. Here is Tor Project's Mastodon account for example and where you can choose an instance:
https://mastodon.social/@torproject/
https://duckduckgo.com/?q=mastodon+instances

Anonymous

Anonymous (not verified) said:

August 25, 2020

Permalink

I'm no expert, but couldn't a middle relay find all the bridges as a passive observer by logging which incoming relays are not in the public list?

Anonymous

John (not verified) said:

August 31, 2020

Permalink

I am wondering if anyone has any insight on how does China's GFW blocks Tor traffic?

Based on my understanding of TorProject, GFW needs to know Tor relay nodes in order to block Tor traffics. Is this correct?

Thanks

The GFW uses several methods:
* Block *.torproject.org using DNS poisoning.
* Block the IP addresses of Tor relays and bridges.
* Use deep packet inspection to detect Tor on the wire.
* Use a crawler to get bridges from bridges.torproject.org.

Join the discussion...

We encourage respectful, on-topic comments. Comments that violate our Code of Conduct will be deleted. Off-topic comments may be deleted at the discretion of the post moderator. Please do not comment as a way to receive support or report bugs on a post unrelated to a release. If you are looking for support, please see our support portal or ways to get in touch with us.

About text formats
CAPTCHA

This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.

9 + 8 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.