meek Pluggable Transport

[phabricator-migrator]

Information

ID: 386
PHID: PHID-TASK-h5l4vc2uyivbqbjtsdwn
Author: HulaHoop
Status at Migration Time: open
Priority at Migration Time: Normal

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: [tor-dev] Preliminary Debian packages for meek

SE instructions: How to install Tor with Meek support on Ubuntu/Debian - Tor Stack Exchange

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: make a deb of meek and get into Debian (#13160) · Issues · Legacy / Trac · GitLab

Comments

---

HulaHoop

2015-07-30 20:48:13 UTC

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.

---

HulaHoop

2015-07-30 23:51:16 UTC

Make an HTTP requestor Firefox extension for meek-client (#11183) · Issues · Legacy / Trac · GitLab

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

2015-11-16 17:47:37 UTC

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

2015-07-31 22:38:23 UTC

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 make TBB usable as "system Tor" (#14121) · Issues · Legacy / Trac · GitLab 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.

GitHub - webfp/tor-browser-crawler: A crawler based on Tor Browser and Selenium
GitHub - isislovecruft/tor-browser-selenium: Selenium-2.0 WebDriver classes for controlling a Tor Browser.

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.

---

HulaHoop

2015-08-01 02:32:50 UTC

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

2016-06-13 13:32:49 UTC

! In T386#6194, @HulaHoop wrote:

• The problems discussed in make TBB usable as "system Tor" (#14121) · Issues · Legacy / Trac · GitLab 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.

GitHub - webfp/tor-browser-crawler: A crawler based on Tor Browser and Selenium
GitHub - isislovecruft/tor-browser-selenium: Selenium-2.0 WebDriver classes for controlling a Tor Browser.

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

---

Patrick

2016-06-13 13:33:05 UTC

! 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:
Whonix Forum

---

HulaHoop

2015-08-02 13:43:32 UTC

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

---

Patrick

2016-06-13 13:31:47 UTC

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

---

Patrick

2016-06-13 13:34:41 UTC

Will be checking on this ticket during porting to #debian_stretch (or +1 more depending on when meek lands in Debian).

---

Patrick

2018-05-12 15:17:10 UTC

Didn’t make it into #debian_stretch. Rechecking in #debian_version_10_codename_buster.

---

Patrick

2018-05-12 15:17:39 UTC

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