Looks like Iceweasel/Firefox is a necessary dependency. Its needed to emulate a normal looking HTTPS connection to Google or Amazon.

To get around the problem of users shooting themselves in the foot and browsing on Whonix Gateway we can restrict what users are allowed to run Iceweasel. Only the Tor user that meek runs under should have run capabilities for the binary. The "user" account should not. Maybe this can be done with chmod.

https://trac.torproject.org/projects/tor/ticket/11183

meek connection needs to bypass Tor proxy settings. I'm not liking this. Could leave room for leaks from GW. But how do we deal with obfsproxy? Is it the same situation?

Did you succeed in setting this up you? Can you share instructions in meanwhile please?

I am not very concerned about iceweasel. Without setting a SocksPort it will be unable to connect. We could also 'config-package-dev hide' its starter. And/or add something similar to https://github.com/Whonix/anon-iceweasel-warning [or extend that package with a gateway specific message].

obfsproxy runs under the same user as Tor itself: debian-tor. That user is allowed to connect to any outside destination. meek should probably under the same user account?

Probably better to wait until this package hits Debian's or The Tor Project's APT repository?
TODO: feature request for adding meek to The Tor Project's APT repository.

There are many pluggable transports. The competing ticket to get all and the most recent of them is this one:
T118

Did you succeed in setting this up you? Can you share instructions in meanwhile please?

I haven't tried it yet. I will have to mask the experimental gateway's traffic or I risk deanonymizing myself. Before I go ahead I wanted to discuss the future direction of pluggable transport support on GW.

• The problems discussed in https://trac.torproject.org/projects/tor/ticket/14121 can be solved even if the features requested are never developed. Running TBB Tor headlessly is possible thru using xvfb (pkg that tricks a gui application into thinking its connected to a X-server) and something like selenium.

https://github.com/webfp/tor-browser-crawler
https://github.com/isislovecruft/tor-browser-selenium

Even when we can run TBB headlessly and still take advanatge of torlauncher-gui I forsee problems that will make the entire idea a non-starter. We cannot redistribute TBB binaries. They must be downloaded. Imagine users in censored areas where they can't connect with Tor how will they be able to fetch TBB when connections to TPO are censored? Downloading from alternative distribution channels using GetTor will leave all kinds of network fingerprints.

The only sane solution is for TPO to spin off torlauncher-gui into its own independent package along with all pluggable transports, all in their repo so we can redistribute them freely and generate builds that include them without problems.

Running Whonix Gateway behind another Whonix Gateway doesn't work for some reason. Any suggestions? I can't run this in the clear when I've already talked about it because it can be linked to me.

In T386#6194, @HulaHoop wrote:

• The problems discussed in https://trac.torproject.org/projects/tor/ticket/14121 can be solved even if the features requested are never developed. Running TBB Tor headlessly is possible thru using xvfb (pkg that tricks a gui application into thinking its connected to a X-server) and something like selenium.

https://github.com/webfp/tor-browser-crawler
https://github.com/isislovecruft/tor-browser-selenium

Even when we can run TBB headlessly and still take advanatge of torlauncher-gui I forsee problems that will make the entire idea a non-starter. We cannot redistribute TBB binaries. They must be downloaded. Imagine users in censored areas where they can't connect with Tor how will they be able to fetch TBB when connections to TPO are censored? Downloading from alternative distribution channels using GetTor will leave all kinds of network fingerprints.

The only sane solution is for TPO to spin off torlauncher-gui into its own independent package along with all pluggable transports, all in their repo so we can redistribute them freely and generate builds that include them without problems.

Answered here:
https://www.whonix.org/old-forum/index.php/topic,720.msg9280.html#msg9280

In T386#6195, @HulaHoop wrote:

Running Whonix Gateway behind another Whonix Gateway doesn't work for some reason. Any suggestions? I can't run this in the clear when I've already talked about it because it can be linked to me.

Answered here:
https://www.whonix.org/old-forum/index.php/topic,1476.msg9283.html#msg9283

Closing this ticket.

Its part of a bigger project of how we want to add pluggable transport support for Whonix, discussed in https://phabricator.whonix.org/T118

Will be checking on this ticket during porting to Debian version 9 codename Stretch (or +1 more depending on when meek lands in Debian).

Didn't make it into Debian version 9 codename Stretch. Rechecking in Debian version 10 codename Buster.

meek might be dead by then:
https://forums.whonix.org/t/replacing-meek-snowflake