Unfortunately meek will soon be dead as domain fronting will be disabled everywhere. Snowflake is the obvious candidate successor because it uses distributed P2P connections and can workaround the domain fronting problem by communicating via DNS-over-HTTPS.
@iry Thanks for your efforts to give us meek. Will it be feasible to integrate snowflake any time soon? What tasks are needed so I can make a roadmap?
Make a deb of snowflake and get into Debian
Below is my very primitive first try:
It doesn’t work and the log is as follows:
[NOTICE] Opening Socks listener on 127.0.0.1:9150
[WARN] The communication stream of managed proxy './TorBrowser/Tor/PluggableTransports/snowflake-client' is 'closed'. Most probably the managed proxy stopped running. This might be a bug o\
f the managed proxy, a bug of Tor, or a misconfiguration. Please enable logging on your managed proxy and check the logs for errors.
[NOTICE] Bootstrapped 5%: Connecting to directory server
[WARN] We were supposed to connect to bridge '0.0.3.0:1' using pluggable transport 'snowflake', but we can't find a pluggable transport proxy supporting 'snowflake'. This can happen if you\
haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
[WARN] Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Can't connect to bridge; PT_MISSING; count 1; recommendation warn; host 2B280B23E1107BB62ABFC40DDCC8824814F80A72\
at 0.0.3.0:1)
[NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
[NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
[NOTICE] Closing old Socks listener on 127.0.0.1:9150
The User Graph show less than 10 people could connect with it successfully, which indicates there may be something wrong with the current snowflake in TBB.
I then tried use snowflake-client with system Tor.
./TorBrowser/Tor/PluggableTransports/snowflake-client from the TBBSet /usr/local/etc/torrc.d/50_user.conf as:
UseBridges 1
ClientTransportPlugin snowflake exec /home/user/QubesIncoming/latest-Tor/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
Tor complains in /var/run/tor/log:
[warn] Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Can't connect to bridge; PT_MISSING; count 6; recommendation warn; host 2B280B23E1107BB62ABFC40DDCC8824814F80A72 at 0.0.3.0:1)
[warn] We were supposed to connect to bridge '0.0.3.0:1' using pluggable transport 'snowflake', but we can't find a pluggable transport proxy supporting 'snowflake'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
If anyone else has the same issue, I will ask for help on tor-dev@.
Is snowflake able to talk directly to the internet in your setup? Reason I ask is it uses STUN to coordinate connections which is UDP.
Same issue here, bootstrapping is stuck at 5%.
First of all, we have to set two variables in order for snowflake-client to run.
Temporary:
export TOR_PT_MANAGED_TRANSPORT_VER=1
export TOR_PT_CLIENT_TRANSPORTS=1
Afterwards, snowflake starts with the following error:
Target URL: snowflake-broker.azureedge.net
Front URL: ajax.aspnetcdn.com
2018/05/23 18:34:59 BrokerChannel Error: dial tcp: lookup ajax.aspnetcdn.com on 10.139.1.2:53: write udp 10.137.0.17:60771->10.139.1.2:53: write: operation not permitted
2018/05/23 18:34:59 Failed to retrieve answer. Retrying in 10 seconds
@hulahoop It looks like you are right about UDP.
Note: Tor Browser 8.0a7 is fully bootstrapping with snowflake in a plain Debian 9 vm.
I used the same environment as troubadour’s:
But I was not able to bootstrap the TBB. It still stuck at 5%.
I have double checked. It seems to work in a Debian vm. To test, I killed snowflake-client after TBB was started and visiting a couple of sites. After killing , it could not connect anywhere.
@iry are you testing on Whonix 14 (Stretch) by any chance?
Hi @HulaHoop !
Thank you for helping me debug. I was testing it on Debian, not Whonix. Now I realize that when I tested the snowflake, I routed all my traffic to China which was behind the GFW. Unfortunately, snowflake did not bypass the censorship this time.
When I tested without routing the traffic to China, it works perfectly well.
I can’t tell if it is because the snowflake protocol has been identified and blocked by the GFW, or it is just because a few well-known snowflake proxies have been censored.
The observation on the packets indicated that snowflake client did several Binding Request to broker using STUN, but it never gets a Binding Success Response from broker.
In uncensored environment, this can be done immediately with a single Binding Request .
This works when running Tor in a Debian-9 VM.
I then tried to port it to Whonix, but failed. Tor complains permission denied when trying to use /etc/tor/snowflake-client:
10:05:02 [WARN] Could not launch managed proxy executable at '/etc/tor/snowflake-client' ('Permission denied').
Tor is run by systemd with root privilege in Whonix. And the Tor default config shipped by Debian is using User debian-tor. Therefore, Tor is actually running by debian-tor.
However, it seems snowflake-client cannot be run by debian-tor user, other user like user and root works fine with it. I tried to chown and chmod, but snowflake-client still cannot be run by debian-tor user:
user@host:~$ ls -l /etc/tor/snowflake-client
-rwx------ 1 debian-tor debian-tor 14160744 Jun 2 09:20 /etc/tor/snowflake-client
user@host:~$ sudo -u debian-tor /etc/tor/snowflake-client
2018/06/02 10:00:52
--- Starting Snowflake Client ---
2018/06/02 10:00:52 No HTTP signaling detected. Using manual copy-paste signaling.
2018/06/02 10:00:52 Waiting for a "signal" pipe...
2018/06/02 10:00:52 open signal: permission denied
Any thoughts on this? 
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:
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...
^Cbetter don’t change permissions of singular files. Then the executed
file cannot look at related files.
chown --recursive debian-tor:debian-tor /path/to/folderThank you for telling me this! 
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.
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.)
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?