Page MenuHomePhabricator

meek Pluggable Transport
Open, NormalPublic

Description

The meek pluggable transport relies on the concept of too big to block to thwart censorship by governments that depend on access to these services.

At the moment it seems meek-http-helper depends on headless Firefox to run using xvfb. This could be a problem but may have since changed.

i386 debs are available.

Investigate if we can include them with obfs4.


Repo keys: https://people.torproject.org/~infinity0/apt/

Official instructions for meek on Debian: https://lists.torproject.org/pipermail/tor-dev/2015-March/008369.html

SE instructions: https://tor.stackexchange.com/a/4074

Source package: https://mentors.debian.net/package/meek
Binary packages: https://people.torproject.org/~infinity0/bin/

make a deb of meek and get into Debian: https://trac.torproject.org/projects/tor/ticket/13160

Details

Impact
Normal

Event Timeline

HulaHoop raised the priority of this task from to Normal.
HulaHoop updated the task description. (Show Details)
HulaHoop added a project: Whonix.
HulaHoop set Impact to Normal.
HulaHoop added a subscriber: HulaHoop.

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?

Patrick added a comment.EditedJul 31 2015, 12:23 PM

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

HulaHoop added a comment.EditedAug 1 2015, 12:36 AM

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.

Patrick added a comment.EditedAug 1 2015, 9:54 AM
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

Patrick added a comment.EditedAug 1 2015, 3:44 PM
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

HulaHoop closed this task as Invalid.Aug 2 2015, 3:43 PM
Patrick updated the task description. (Show Details)Nov 16 2015, 6:44 PM
Patrick reopened this task as Open.Jun 13 2016, 3:31 PM
In T386#6199, @HulaHoop wrote:

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

Since we are no longer going for T118, reopen.

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