Replacing meek: Snowflake

Yes, any of the following, apparmor or seccomp is likely the cause.

cat /lib/systemd/system/tor@default.service

apparmor:

# Hardening
AppArmorProfile=system_tor

seccomp:

NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectHome=yes
ProtectSystem=full
ReadOnlyDirectories=/
ReadWriteDirectories=-/proc
ReadWriteDirectories=-/var/lib/tor
ReadWriteDirectories=-/var/log/tor
ReadWriteDirectories=-/var/run
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE
CAP_DAC_OVERRIDE
1 Like

Thank you so much for your instructions, @Patrick !

As you pointed out, the problem turns out to be a common apparmor issue which has been fixed by:

https://github.com/Whonix/anon-gw-anonymizer-config/pull/10/commits/f6dc5849d7f209b2bc0bae6335e70e91e0311bf1


For Qubes-Whonix, it can be tested as follows:

First, open Whonix-Gateway Template, and write the line below to /etc/apparmor.d/local/system_tor and shutdown the template:
/usr/bin/snowflake-client rix,

Second, open an AppVM that is based on it, and extract the snowflake-client executable from the latest experimental TBB to /usr/bin:
sudo install -o debian-tor -g debian-tor -m 700 snowflake-client /usr/bin/

Third, restart Tor with:
systemctl restart tor

Now, Tor is using snowflake in Whonix-Gateway!

1 Like

Whoops, I forgot to say the torrc file in AppVM should look like this:

user@host:~$ cat /usr/local/etc/torrc.d/50_user.conf
UseBridges 1
ClientTransportPlugin snowflake exec /usr/bin/snowflake-client -url https://snowflake-broker.azureedge.net/ -front ajax.aspnetcdn.com -ice stun:stun.l.google.com:19302 -max 3
Bridge snowflake 0.0.3.0:1 2B280B23E1107BB62ABFC40DDCC8824814F80A72
1 Like

Next tasks:

  • Get snowflake-client into Whonix-Gateway
  • Let anon-connection-wizard support snowflake

There are three ways to complete task 1, the methods below should be applicable to many other censorship circumvention tools shipped with TBB :

  1. Wait until snowflake-client gets into Debian: Make a deb of snowflake and get into Debian (#19409) ¡ Issues ¡ Legacy / Trac ¡ GitLab
  • pros: Whonix developers only need to include snow-flake and future maintenance cost is nearly zero.
  • cons: Needs someone to make it into Debain, considering the fate of meek, this may never happen.
  1. Use a script to download the latest experimental TBB in Whonix-Gateway and extracted the snowfalke-client executable.
  1. Whonix distributes the executable ourselves
  • pros: more controls by Whonix and it should be more stable
  • cons: trust issue, a lot of extra work for Whonix developer
1 Like

Doesn’t work for users under censorship?

1 Like

Great question!

All the traffic in Whonix-Gateway is enforced to go through Tor so if when Tor can’t connect to the network but we need to download something without Tor, it becomes a chicken-egg problem. Right?


If we can temporarily and safely allow a clearnet connection, then Github may be the best way to download experimental TBB:

Done:

Once we get snowflake-client into Whonix-Gateway, I will merge this branch into master branch. :wink:

//cc @HulaHoop

iry:

Great question!

All the traffic in Whonix-Gateway is enforced to go through Tor so if when Tor can’t connect to the network but we need to download something without Tor, it becomes a chicken-egg problem. Right?

That’s it.

If we can temporarily and safely allow a clearnet connection, then Github may be the best way to download experimental TBB:

It’s possible.

We could do gpg verification, we have such code in tb-updater which
could be made into tpo-downloader but very messy:

1 Like

iry:

  1. Whonix distributes the executable ourselves
  • pros: more controls by Whonix and it should be more stable
  • cons: trust issue, a lot of extra work for Whonix developer

We could handle it “same way we handle Tor Browser default installation
in Whonix-Workstation”.

It would require (major work…):

  • transforming tb-updater into tb-downloader (just a better name, no
    actual separate development step, just conceptual for explanation) since
    it’s really a downloader, not updater (doesn’t persist user settings
    like TBB internal updater)

  • transforming tb-downloader into tpo-downloader

  • installing tpo-downloader by default on Whonix-Gateway

  • download, verify, extract snowflake during the build of Whonix (like
    tb-updater currently does for Tor Browser on Whonix-Workstation)

Minor (details, easy):

  • making the Tor Browser Downloader (by Whonix developers) launcher
    invisible on Whonix-Gateway using config-package-dev displace (easy
    since I did it before many times, existing code examples in Whonix code,
    I can handle)

  • making the snowflake Downloader (by Whonix developers) launcher
    invisible on Whonix-Workstation using config-package-dev displace (easy
    since I did it before many times, existing code examples in Whonix code,
    I can handle)

1 Like

iry:

There are three ways to complete task 1, the methods below should be applicable to many other censorship circumvention tools shipped with TBB :

  1. Wait until snowflake-client gets into Debian: Make a deb of snowflake and get into Debian (#19409) ¡ Issues ¡ Legacy / Trac ¡ GitLab
  • pros: Whonix developers only need to include snow-flake and future maintenance cost is nearly zero.
  • cons: Needs someone to make it into Debain, considering the fate of meek, this may never happen.

This is the very very best solution.

Even snowflake available von deb.torproject.org would be better than anything below which is very hacky, very maintenance intense long time.

“considering the fate of meek, this may never happen.” - Why? How is snowflake being blocked by meek?

  1. Use a script to download the latest experimental TBB in Whonix-Gateway and extracted the snowfalke-client executable.
  • pros: the script will be simple

Not simple unless file hashes are hardcoded since gpg verification automation done right is hard.

  • cons: need to figure out how to run the script regularly, a lot of maintenance work

Yes.

Correct.

1 Like

I was thinking that meek never got into Debian because of the lack of manpower and cooperation. Will snowflake suffer from the same fate that it keeps waiting for someone to get it into Debian?

1 Like

I agree. Here are the 4 ways to distribute snowflake binary:

  1. Distribute it from deb.torproject.org
  • pro: a little bit easier than getting it into Debian
  • con 1: torproject.org is already censored, causing a chicken-and-egg problem
  • con 2: still needs someone from TPO to get it into deb.torproject.org
  1. Distribute it from Debian repository
  • pro: Debian repository is not censored in China
  • con 1: need a Debian Maintainer to do the job (It’s actually really cool if I can do the job but I still need to learn more about Debian packaging and policy.)
  • con 2: It needs the approval from TPO. I remember infinity0 was ready to get meek into Debian but never got a response from TPO.
  1. Distributing it from Whonix repository
  • note: Whonix repository is not censored by GFW yet but blocking it won’t cost as much as blocking Debian repository.
  1. Distributing it from Whonix Github
  • pros: Github is not censored by GFW and download from it will be really fast
  • cons: User must trust Whonix.
1 Like

I am not sure why “gpg verification automation done right is hard”. Would you please explain it a little bit more?

1 Like

@iry don’t worry about how someone in a censorship zone can bootstrap the Whonix build process. If we assume the user has a currently connecting version and/or managed to get their first image smuggled into the country via sneakernet, it simplifies the model greatly and so using deb.torproject.org becomes the obvious choice to add snowflake support (is it included there now?)

If snowflake is not packaged by Tor devs yet then the next best solution for now is to use the bundled transports in Tor Browser (which we would now include on the GW too) and hide it from the user. I remember we considered this for another ticket too (where we wanted curl to use the torproject.org self signed key when checking for updates to secure it against MITM from exits). This solution has the great advantage where we can make use of the latest and greatest transports now and in the future without having to wait for packaging by any upstream teams. It is also the most realistic path (though inconvenient) if what our past experience is anything to go by. Hopefully after going thru it once it will be set and forget and we can take advantage of it in the future without problems.

2 Likes

iry:

[quote=“Patrick, post:31, topic:5190”]
“considering the fate of meek, this may never happen.” - Why? How is
snowflake being blocked by meek?
[/quote]

I was thinking that meek never got into Debian because of the lack of
manpower and cooperation. Will snowflake suffer from the same fate that
it keeps waiting for someone to get it into Debian?

Possibly. However, should someone wish to contribute then time spent on
the packaging way is much better spent then solutions below.

iry:

I agree. Here are the 4 ways to distribute snowflake binary:

  1. Distribute it from deb.torproject.org
  • pro: a little bit easier than getting it into Debian
  • con 1: torproject.org is already censored, causing a chicken-and-egg problem

Yes, but only matters for downloaded by user after boot based
approaches. Doesn’t matter for preinstallation / installation during
Whonix build.

  1. Distribute it from Debian repository
  • pro: Debian repository is not censored in China

Same. Preinstallation / installation during Whonix build would even work
when deb.torproject.org and packages.debian.org both would be censored.

  • con 1: need a Debian Maintainer to do the job (It’s actually really cool if I can do the job but I still need to learn more about Debian packaging and policy.)
  • con 2: It needs the approval from TPO. I remember infinity0 was ready to get meek into Debian but never got a response from TPO.

I don’t think packing Libre Software and uploading to Debian requires
approval from TPO.

  1. Distributing it from Whonix repository
  • note: Whonix repository is not censored by GFW yet but blocking it won’t cost as much as blocking Debian repository.

Same.

  1. Distributing it from Whonix Github
  • pros: Github is not censored by GFW and download from it will be really fast

Same.

  • cons: User must trust Whonix.

If pre-installed during build of Whonix: Same trust issue same as
currently existing with Tor Browser default installation in
Whonix-Workstation.

iry:

[quote=“Patrick, post:31, topic:5190”]
Not simple unless file hashes are hardcoded since gpg verification
automation done right is hard.
[/quote]

I am not sure why “gpg verification automation done right is hard”.
Would you please explain it a little bit more?

Not yet: Make a deb of snowflake and get into Debian (#19409) ¡ Issues ¡ Legacy / Trac ¡ GitLab


Yes! This solution looks very promising to me. :slight_smile:

I agree that it won’t affect Whonix build process.

I still would like to emphasis that having a reliable upgrading path is very important to a censorship circumvention tool. This is because the upgrade of GFW will paralyze the censorship circumvention tools and this always happens unexpectedly. Even if later the circumvention tools got updated, it is still hard for user in censored area to get the latest copy of it.


Let me try this as my next step: :wink:

1 Like

https://github.com/Whonix/anon-gw-anonymizer-config/pull/12

1 Like

any update on this?

1 Like

The Tor Project released an addon for Firefox and Chrome so that one can easily run snowflake proxies. You can find their links in this page: snowflake (dot) torproject (dot) org

Snowflake if you don’t know is a WebRTC pluggable transport for Tor.

By the way what is the current status on Snowflake support in Whonix? Is there anything more recent than github (dot) com/Whonix/anon-connection-wizard/pull/22 ?