Opened 3 years ago

Last modified 13 months ago

#13160 new defect

make a deb of meek and get into Debian

Reported by: proper Owned by: dcf
Priority: Medium Milestone:
Component: Obfuscation/meek Version:
Severity: Normal Keywords:
Cc: proper, andz@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

aka

apt-get install meek

Speaking for Whonix, this would be very useful. Perhaps for Tails as well, but I am not speaking for them.

Child Tickets

Change History (15)

comment:1 Changed 3 years ago by dcf

I think you will want separate client and server packages.

infinity0 did a bunch of work designing Debian packages for flash proxy. Note for example the "pt-" prefix on the server package.

Here is the FreeBSD port: https://www.freshports.org/security/meek/. I think it includes both client and server.

Do you have an idea of how to enable the browser camouflage (#11183, #11393) in a Debian package? At the moment it's fairly coupled to Tor Browser.

comment:2 Changed 3 years ago by proper

I think you will want separate client and server packages.

Yes.

infinity0 did a bunch of work designing Debian packages for flash proxy.

Awesome!

Do you have an idea of how to enable the browser camouflage (#11183, #11393) in a Debian package?

Unfortunately, not. I'll notify on tails-dev mailing list, perhaps they have ideas.

comment:3 Changed 3 years ago by infinity0

ITP filed: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764007

I plan to make four packages: server, client, firefox extension, and reflector all-in-one package.

The Firefox extension is easy to package, there are already many extensions in Debian. This should be quite easy to do.

Chromium is deficient in this area; there are currently no Chromium extensions in Debian for this reason. I don't know if they will do this soon. http://code.google.com/p/chromium/issues/detail?id=420373

One possible hack (for a Chromium extension package) in the meantime is to distribute a private key alongside the build scripts, but I'm not sure if other Debian people would let me do that.

comment:4 Changed 3 years ago by proper

Posted here:

pkg-anonymity-tools mailing list is apparently a good place to discuss this. I am sorry, I am not great at relaying messages here and there. If you have any packaging questions, please consider signing up there.

comment:5 follow-up: Changed 3 years ago by infinity0

#12716 should be fixed before we package this for Debian. The fix is fairly straightforward, turning it into a generic helper/wrapper script, mentioned in ticket:12716#comment:5

comment:6 in reply to: ↑ 5 Changed 3 years ago by dcf

Replying to infinity0:

#12716 should be fixed before we package this for Debian. The fix is fairly straightforward, turning it into a generic helper/wrapper script, mentioned in ticket:12716#comment:5

#12716 is one way forward, but it's not the only way. I would say, don't wait for #12716 before packaging for Debian. All the proposed fixes on that ticket are pretty kludgy and I'm not prepared to merge any of them.

A reasonable solution (it seems to me) is to fork meek-client-torbrowser into a meek-client-debian-firefox or whatever, that knows all the Debian-specific paths. Then at least we'll have another data point to help settle what we actually need for #12716.

comment:7 Changed 3 years ago by dcf

The Chrome extension is pretty unmaintained at this point. I would suggest just packaging the Firefox one until that changes.

comment:8 Changed 3 years ago by infinity0

I wasn't going to wait; rather I was intending to submit a patch along the lines of ticket:12716#comment:5 - do you think that's kludgy as well? (Please comment on that ticket if you think so.) It would be preferable for Debian to maintain as few upstream-deviated files as possible. Under any usage scenario the helper program would be required, so it is not really a TBB- or Debian-specific thing.

Yes, I will leave the Chrome extension for now; upstream seem pretty uninterested in putting in effort to support it, and I don't have time to write a patch that big for Chrome.

comment:10 follow-up: Changed 18 months ago by irl

  • Severity set to Normal

This is blocking #17964 that will allow for the ooniprobe raspberry pi images to easily perform upgrades without having to ship a full Go build environment in the image. We really need to have the image as small as possible to ensure it's as accessible as possible.

comment:11 in reply to: ↑ 10 Changed 18 months ago by dcf

Replying to irl:

This is blocking #17964 that will allow for the ooniprobe raspberry pi images to easily perform upgrades without having to ship a full Go build environment in the image. We really need to have the image as small as possible to ensure it's as accessible as possible.

A possible workaround for you, if you are not using the web browser camouflage, is the meek-lite support in obfs4proxy.

https://gitweb.torproject.org/pluggable-transports/obfs4.git/commit/?id=611205be681322883a4d73dd00fcb13c4352fe53

But that doesn't seem to have gotten a proper release yet.

comment:12 Changed 18 months ago by infinity0

Here are some updated packages: https://people.debian.org/~infinity0/apt/pool/contrib/m/meek

But I don't want to upload them to Debian officially yet until #12716 is fixed. We *know* that fingerprinting is possible, so we ought to ensure that the browser-helper works on as many systems as possible. (I don't want a separate solution for Debian that isn't given any attention by upstream, because that's not a sustainable solution. It would be much better if Debian and meek+TorBrowser use the same underlying mechanism with a few variables changed.)

TL;DR: the latest situation is that I am waiting for (i.e. blocked on) a reply to my latest patch on that bug.

comment:13 Changed 18 months ago by anadahz

  • Cc andz@… added
  • Parent ID set to #17964

comment:14 Changed 16 months ago by 6h72Q484AddGha8H

FYI, if AppArmor is enabled, the default Tor policy will block execution of the meek-client executable. A message like the following will be encountered upon running Tor via the service system:

"[warn] Could not launch managed proxy executable at '/usr/bin/meek-client' ('Operation not permitted')."

Running Tor as the root user bypasses the AppArmor policy and works fine, but you want it to work when called via automated service commands. The fix is to add the following line to the profile at /etc/apparmor.d/system_tor:

/usr/bin/meek-client ix,

This allows tor to callout to the meek-client without violating AppArmor by inheriting the execution policy ("ix"). Then you can restart both apparmor and tor and everything should work fine.

$ sudo service apparmor restart
$ sudo service tor restart

Note: Tested on Ubuntu 15.10, but adding here so that when officially packaged, both distros will work with AppArmor.

comment:15 Changed 13 months ago by anadahz

  • Parent ID #17964 deleted
Note: See TracTickets for help on using tickets.