[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Replacing meek: Snowflake

The culprit could be that you extracted snowflake to a location that does not support the same type file permissions (shared folder device running another type fs) then copied it from there. Try moving the tarball to the GW first then extracting there?

Source:

1 Like

It seems snowflake-client still cannot be executed by debian-tor user. Here is the full operations:

Here is the original permission and ownership of snowflake-client:

user@host:~$ ls -l snowflake-client  
-rwx------ 1 user user 14160744 Jun  4 06:17 snowflake-client

It can be executed by user user:

user@host:~$ sudo -u user ./snowflake-client 
2018/06/04 06:18:21 


 --- Starting Snowflake Client ---
2018/06/04 06:18:21 No HTTP signaling detected. Using manual copy-paste signaling.
2018/06/04 06:18:21 Waiting for a "signal" pipe...
^C

We now change the permission to let it executable by user debian-tor:

user@host:~$ sudo chmod 777 snowflake-client 


user@host:~$ sudo -u debian-tor ./snowflake-client 
2018/06/04 06:18:43 

Noticed the permission denied:

 --- Starting Snowflake Client ---
2018/06/04 06:18:43 No HTTP signaling detected. Using manual copy-paste signaling.
2018/06/04 06:18:43 Waiting for a "signal" pipe...
2018/06/04 06:18:43 open signal: permission denied

We now change its ownership to debian-tor:debian-tor:

user@host:~$ sudo chown debian-tor:debian-tor snowflake-client 
user@host:~$ ls -l snowflake-client 
-rwxrwxrwx 1 debian-tor debian-tor 14160744 Jun  4 06:17 snowflake-client

Still, permission denied:

user@host:~$ sudo -u debian-tor ./snowflake-client 
2018/06/04 06:19:15 


 --- Starting Snowflake Client ---
2018/06/04 06:19:15 No HTTP signaling detected. Using manual copy-paste signaling.
2018/06/04 06:19:15 Waiting for a "signal" pipe...
2018/06/04 06:19:15 open signal: permission denied

However, when executing it by user, it works fine:

user@host:~$ sudo -u user ./snowflake-client 
2018/06/04 06:19:22 


 --- Starting Snowflake Client ---
2018/06/04 06:19:22 No HTTP signaling detected. Using manual copy-paste signaling.
2018/06/04 06:19:22 Waiting for a "signal" pipe...
^C

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
1 Like

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.

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.

1 Like

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

1 Like

Asked on the tor-dev@:

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

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:

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:


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

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

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

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
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]