Enable uTLS and use the full bridge line for snowflake

Resolves #40654 (closed)

In some networks they block snowflake on mobile phones by it's TLS fingerprint, let's use uTLS by default.

Including the full bridge line helps for other clients that don't have the default params already configured when launching snowflake client.

Related: tpo/anti-censorship/team#101 (closed) tpo/anti-censorship/team#96 (closed)

Before merging this I would like the confirmation from @dcf and @shelikhoo that we do want to enable uTLS for everybody by default. If not I'm happy to remove the uTLS from here and just keep the full bridgeline.

Okay, marking as draft, then .

I believe that uTLS can be identified by censor that try to change their detection system specifically for uTLS. So, it would be better if we enable it selectively. We can wait a little longer for @dcf 's opinion on this.

Yes, the intention is to enable uTLS by default for everyone. There is no reason to activate it selectively only for certain regions. (And anyway, we have no technical mechanism for activating uTLS for only certain users, except for Connection Assist, which as I understand it does not work for Android, which is where the change is most needed.) It would be better if there were a way to select from a weighted random selection of real fingerprints (I believe this is what Psiphon does), but because there is no feature to do that yet, hellorandomizedalpn is the best we can do.

The intention of tpo/anti-censorship/pluggable-transports/snowflake#40054 (closed) was always to enable to TLS camouflage for all users. The native Golang TLS fingerprint is the wrong choice basically everywhere. It's not like TLS camouflage is an expensive resource whose use we have to conserve. It's a basic necessity of TLS-based circumvention and going without it is a bug.

I am a little worried about compatibility, simply because we have not done large-scale testing. We have not yet had reports of either success or failure from Iran from the BBS or the Tor forum. The hellorandomizedalpn fingerprint has been working for me in my own browser since yesterday, and I've bootstrapped a command-live version from a vantage in Iran. uTLS is a pretty widely used library, it's not like this is something entirely novel. Still, there is a risk with any large deployment.

Another argument for enabling uTLS by default: Tor Browser's meek implementation has used uTLS (using Yawning's fork) since tor-browser#29430 (closed) in 2019. The client hello ID it uses is hellofirefox_65, which in my test just now produces the fingerprint 6bfedc5d5c740d58.

Let's talk about this tomorrow in our weekly meeting.

There's a success report from Iran.

https://github.com/net4people/bbs/issues/131#issuecomment-1284211012

just tested tor browser on android with ur custom snowflake, and it works, not perfectly or fast, but does connect and brings certain restricted websites.

There's also a failure report from Iran using manually entered utls-imitate:

https://github.com/net4people/bbs/issues/125#issuecomment-1285003475

It is 11.5.4. A friend told me that neither hellochrome_auto nor hellorandomizedalpn was working on his phone. But the snowflake option itself (without custom bridge) was working!

Snowflake in Tor Browser for Android working without any custom utls agrees with what @gus reported at tpo/anti-censorship/team#96 (comment 2845567):

Tor Browser for Android + Snowflake [Tor Browser for Android 11.5.4 (without any bridge line changes)] works, but Orbot (iOS and Android) with snowflake is not working.

2022-10-20 meeting discussion log:

http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-10-20-15.58.log.html#l-40

mentioned in issue tpo/anti-censorship/team#96 (closed)

mentioned in issue tpo/anti-censorship/team#101 (closed)

assigned to @pierov

assigned to @meskio and unassigned @pierov

requested review from @pierov

marked this merge request as draft

I just noticed that the merge request adds the parameters to the bridge line in projects/common/bridges_list.snowflake.txt, but does not remove them from projects/browser/Bundle-Data/PTConfigs/*/torrc-defaults-appendix. Here's an additional commit that removes the parameters from torrc-defaults-appendix.

https://gitlab.torproject.org/dcf/tor-browser-build/-/commits/snowflake-full-bridgeline

Parameters in the bridge line override parameters from the command line, but there is no way to "unset" a parameter on a bridge line, if the parameter is set on the command line. Currently it's not a problem to have the same set of parameters specified in both places, because the bridge line will win. But it could be a problem in the future to have non-overridable parameters set on the command line, if we introduce a rendezvous method that does not use the url or front parameters, for example.

Great, I added your commit into this merge request.

added 1 commit

• 4cbd4d94 - Remove command line options from snowflake-client.

Compare with previous version

We have agreed to move forward with this merge request.

@pierov do you mind having a look to it and see if is ready to merge?

@meskio lgtm, you'll probably need to rebase it to current HEAD, or I can cherry-pick.

Also, do you need this in stable, right?

Yes, this is for stable. Thank you for the cherrypick.

marked this merge request as ready

mentioned in issue #40654 (closed)

changed the description

Cherry-picked to main as 53498bf0 and as ec85353e.

@richard will let you close after we backport.

cherry-picked to maint-11.5 as 6a8c634d and 69d77eba

closed

mentioned in issue #40665 (closed)

mentioned in commit dcf/snowflake@a055ece1

mentioned in merge request tpo/anti-censorship/pluggable-transports/snowflake!132 (merged)

mentioned in commit dcf/snowflake@b443e994

mentioned in issue #40740 (closed)

mentioned in issue #40941 (closed)