[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

Replacing meek: Snowflake


#15

better don’t change permissions of singular files. Then the executed
file cannot look at related files.

chown --recursive debian-tor:debian-tor /path/to/folder

#16

Thank you for telling me this! :slight_smile:

I tried to extract the tar after sending it to the targeted gateway and then do the chown -R on the entire TBB folder. It still does not work with debian-tor user.


#17

Still permission denied errors?

Perhaps snowflake wants to write into ~/ home, which then wouldn’t be possible. There is no debian-tor home folder (not usual to have home folders for system users) and as for user’s home folder, there would be permission denied.

Can snowflake data dire be specified on command line or in config somehow?

Idea… In a non-Whonix test VM… Put a whole home folder under git control. Add all files to git. Start snowflake. Stop snowflake. Use git status to see what files are new or modified.


#18

For testing only.

sudo mkdir /home/debian-tor
sudo chown -R debian-tor:debian-tor /home/debian-tor
sudo su debian-tor

(In final version we could not use /home/debian-tor. snowflake-client would have to be a in a proper location and access rights sorted out.)


#19

Asked on the tor-dev@:

https://lists.torproject.org/pipermail/tor-dev/2018-June/013210.html


#21

Tested on both Debian-9 and Whonix-14-Gateway.

I suspected that the issue is related to systemd.

Here are the steps on Whonix-14-Gateway:

First, write confs below to /usr/local/etc/torrc.d/50_user.conf:

DisableNetwork 0
UseBridges 1
ClientTransportPlugin snowflake exec /home/user/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

Then do systemctl restart tor and it will complain permission denied.

Now let’s see what systemd really executed:

user@host:~$ grep "ExecStart=" /lib/systemd/system/tor@default.service                                                                                                                                                                        
ExecStart=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0                                                                                                                           

We executed the command ourselves with sudo:

sudo /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0

And yes, there will be no complain about “permission denied” and Tor will successfully connect to the Tor network (it may take a little bit time).


This indicates systemd does not necessarily work as sudo command-in-the-execstart-section.

To do further investigation into the problem, I need to learn more about how systemd really works.

Any thoughts on this? :slight_smile:


#22

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

#23

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:


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!


#24

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

#25

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: https://trac.torproject.org/projects/tor/ticket/19409
  • 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

#26

Doesn’t work for users under censorship?


#27

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:

https://trac.torproject.org/projects/tor/ticket/26175#ticket


#28

Done:

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


#29

//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:


#30

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)


#31

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: https://trac.torproject.org/projects/tor/ticket/19409
  • 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.


#32

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?


#33

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.

#34

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


#35

@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.