Feature #15331

Support automatic bridge retrieval in Tor Launcher (Moat)

Added by intrigeri 2018-02-20 08:22:44 . Updated 2020-04-30 16:39:56 .

Status:
In Progress
Priority:
Elevated
Assignee:
Category:
Tor configuration
Target version:
Start date:
2017-12-12
Due date:
% Done:

10%

Feature Branch:
wip/feature/15331-moat
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Tor Launcher
Deliverable for:

Description

Feature #15064 was supposed to track that but it’s been repurposed to integrating in Tails the subset of that work that was ready when we prepared Tails 3.5. This ticket is meant to track everything that’s left on https://trac.torproject.org/projects/tor/query?component=Applications%2FTor+Launcher&sponsor=Sponsor4 i.e. automatic retrieval of bridges (moat).

What moat gives is the “request a bridge” button in Tor Launcher, which appeared in Tor Browser 8.0. When pressed, after solving a CAPTCHA, one gets bridges from BridgeDB automatically.

(sajolida wants to follow this)


Subtasks


Related issues

Related to Tails - Feature #8243: Support meek bridges In Progress 2014-11-08
Related to Tails - Bug #11535: Fail at setting Tor bridge mode when using Unsafe Browser to get bridges Confirmed 2016-06-16
Related to Tails - Feature #5461: Persistence preset: Tor configuration Confirmed
Blocks Tails - Feature #8825: Provide default bridges Confirmed 2015-01-30
Copied from Tails - Feature #15064: Adapt to Tor's Sponsor4 Tor Launcher UX improvements Resolved 2017-12-12

History

#1 Updated by intrigeri 2018-02-20 08:22:45

  • copied from Feature #15064: Adapt to Tor's Sponsor4 Tor Launcher UX improvements added

#2 Updated by intrigeri 2018-02-20 08:23:14

#3 Updated by intrigeri 2018-02-20 08:23:25

#4 Updated by intrigeri 2018-02-20 08:23:34

#5 Updated by intrigeri 2018-02-20 08:28:13

  • Status changed from New to Confirmed
  • Priority changed from Normal to Elevated
  • Target version set to Tails_3.6
  • Type of work changed from Code to Communicate

I think next step is to talk to Tor Browser folks in order to know when they plan to release this:

  • either in an alpha TB (which would allow us to start working on this in a relaxed way :)
  • directly in a stable TB (which might imply we have to handle this with high priority for 3.6 or 3.7, or at least ensure the upstream code/UI supports the case when the OS breaks moat support somehow); gk said it was supposed to land in 7.5 and if I understood right, they had to request a contact extension from their sponsor in order to complete this work late but by the end of February, so I wouldn’t be surprised if they ship this in the March stable TB.

Can you handle the communication part this week? If not, let me know ASAP and I’ll do it as part of my triage/prioritize/dispatch tasks job :)

#6 Updated by anonym 2018-02-21 11:50:46

  • Type of work changed from Communicate to Code

intrigeri wrote:
> I think next step is to talk to Tor Browser folks in order to know when they plan to release this:
>
> * either in an alpha TB (which would allow us to start working on this in a relaxed way :)

On the main ticket alpha builds have been published: https://people.torproject.org/~brade/testbuilds/moat-2018-02-15/ so I can start working on this (based on Bug #8775).

> * directly in a stable TB (which might imply we have to handle this with high priority for 3.6 or 3.7, or at least ensure the upstream code/UI supports the case when the OS breaks moat support somehow); gk said it was supposed to land in 7.5 and if I understood right, they had to request a contact extension from their sponsor in order to complete this work late but by the end of February, so I wouldn’t be surprised if they ship this in the March stable TB.

This is what I’ve been expecting. I’m very glad for the work on Bug #8775 already done. :)

> Can you handle the communication part this week? If not, let me know ASAP and I’ll do it as part of my triage/prioritize/dispatch tasks job :)

Done: https://trac.torproject.org/projects/tor/ticket/24689#comment:1

#7 Updated by anonym 2018-02-21 12:02:41

  • Target version changed from Tails_3.6 to Tails_3.9
  • Feature Branch set to feature/15331-moat

anonym wrote:
> intrigeri wrote:
> > Can you handle the communication part this week? If not, let me know ASAP and I’ll do it as part of my triage/prioritize/dispatch tasks job :)
>
> Done: https://trac.torproject.org/projects/tor/ticket/24689#comment:1

We already got an answer from gk: “I estimate it will be available in Tor Browser 8.0 which is supposed to get out at the end of August” == Tails 3.9. While there’s no emergency starting to work on this, I’ve imported the Moat-enabled alpha build into a branch just to see where we are currently at.

#8 Updated by anonym 2018-02-21 14:58:57

  • Status changed from Confirmed to In Progress

Applied in changeset commit:fe08b248a1fc52271c027afc59b0945bb70ff26c.

#9 Updated by anonym 2018-02-22 15:07:07

  • % Done changed from 0 to 10

I’m not sure, but I think we’ll need the full meek client for this. :/ Tor Button 8.0a1’s Tor Launcher depends on Tor having ClientTransportPlugin meek exec ... set, so even if meek_lite works, we’ll need that code to support us. I only did some very quick hacks to test both meek and meek_lite, but got neither to work. Any way, there’s no hurry.

#10 Updated by intrigeri 2018-02-26 11:38:10

#11 Updated by intrigeri 2018-02-26 11:38:19

#12 Updated by intrigeri 2018-02-26 13:27:32

  • related to Bug #11535: Fail at setting Tor bridge mode when using Unsafe Browser to get bridges added

#13 Updated by intrigeri 2018-04-08 13:55:55

  • blocked by deleted (Feature #13245: Core work 2018Q1: Foundations Team)

#14 Updated by intrigeri 2018-04-08 13:55:59

#15 Updated by intrigeri 2018-06-01 05:05:56

  • blocked by deleted (Feature #15139: Core work 2018Q2: Foundations Team)

#16 Updated by intrigeri 2018-06-01 05:06:53

  • Assignee deleted (anonym)
  • Target version deleted (Tails_3.9)

Let’s put this on the back burner until the dust settles wrt. domain fronting, which the current version of moat relies upon.

#17 Updated by intrigeri 2018-09-06 08:17:53

Tor Browser 8 was released with Moat support.

#18 Updated by sajolida 2018-10-01 14:29:18

  • Description updated

Adding my name to the description so I receive notifications :)

#19 Updated by intrigeri 2019-03-08 15:19:50

  • Status changed from In Progress to Confirmed

#20 Updated by intrigeri 2019-08-11 17:46:56

  • Subject changed from Adapt to Tor's Sponsor4 Tor Launcher UX improvements: moat to Support automatic bridge retrieval in Tor Launcher (moat)
  • Description updated

#21 Updated by intrigeri 2019-08-11 17:49:08

intrigeri wrote:
> Let’s put this on the back burner until the dust settles wrt. domain fronting, which the current version of moat relies upon.

A year later, in Tor Browser 8.5.4, moat works just fine (using meek-azure). So I think we can resume work here whenever we want+can.

#22 Updated by intrigeri 2019-08-11 17:51:49

  • related to Feature #5461: Persistence preset: Tor configuration added

#23 Updated by intrigeri 2019-08-11 18:04:58

  • Subject changed from Support automatic bridge retrieval in Tor Launcher (moat) to Support automatic bridge retrieval in Tor Launcher (Moat)
  • Description updated

#24 Updated by intrigeri 2019-08-11 20:43:59

  • Status changed from Confirmed to In Progress

Applied in changeset commit:tails|f62ad368ab18bdf1770cbfb201d49190ba0e8b0e.

#25 Updated by intrigeri 2019-08-11 20:46:57

  • Status changed from In Progress to Confirmed
  • Feature Branch changed from feature/15331-moat to wip/feature/15331-moat

I’ve rebased the branch on current devel and made it build. I was curious to see how far we were from something that could possibly work.

tl;dr: quite some work is needed to make Moat work on Tails. Moat integration kind of assumes a regular Tor Browser, while our own thing is, well, special.

The Tor Launcher code says that meek_lite is supported; not sure if it’s ever been tested, though. onOpenBridgeDBRequestPrompt chooses what meek client it’ll use by looking at ClientTransportPlugin via GETCONF. So I’ve made the Tor Launcher config use meek as well, for consistency.

“The Tor data directory does not exist and could not be created” → datadir_missingsrc/modules/tl-bridgedb.jsmsrc/modules/tl-util.jsm (getTorFile). That’s about extensions.torlauncher.tordatadir_path. I don’t know if we should create the directory this points to by default (/home/tor-launcher/Tor) or point it to /var/lib/tor. It might be that the whole thing really expects to be able to share a datadir with the instance of tor it’s using, which might be tricky in our case. We might end up having to run Tor Launcher as debian-tor.

If I create /home/tor-launcher/Tor, it goes a bit further and I get “The meek client exited unexpectedly during the pluggable transport handshake”, which can be caused by a variety of reasons as show below; I did not tweak things to get debug output, so whatever.

Apart of that, Tor Launcher runs meek itself, so likely we’ll need to open up the firewall a bit. But stopping ferm is not sufficient to make things work.

Finally, in a proper installation of Tor Browser, there’s Browser/TorBrowser/Data/Browser/profile.{moat-http-helper,meek-http-helper}; both contain the meek-http-helper extension and a custom user.js. We need all this stuff to make the thing work: to request bridges (or just to solve the CAPTCHA? I did not investigate), Tor Launcher runs another (invisible) instance of firefox.real with the Browser/TorBrowser/Data/Browser/profile.moat-http-helper profile. Also, I suspect it runs Browser/firefox.real from the current working directory and it won’t find it.

#26 Updated by intrigeri 2019-09-03 09:48:41

OK, good news (I think)!

In Tor Browser 9, meek-http-helper, that was added complexity and causing trouble here, is going away: https://trac.torproject.org/projects/tor/ticket/29430. To understand the big picture, also see the child tickets, https://trac.torproject.org/projects/tor/ticket/29077, and https://trac.torproject.org/projects/tor/ticket/29347.

Also, if I got it right, Tor Browser is switching from the meek client to using obfs4proxy’s meek_lite. This is good because it’s closer to what we do. But if I got it right, they could do it because the new version of obfs4proxy they’re using uses its own, forked uTLS: https://trac.torproject.org/projects/tor/ticket/29077, https://trac.torproject.org/projects/tor/ticket/29627. There seems to be little chances Debian can match this any time soon, so if we want our meek client to have the same fingerprint as Tor Browser’s, likely we’ll need to use the binary of obfs4proxy bundled with Tor Browser instead of the one from Debian. I don’t know if this is relevant on this ticket so I’ll also add the info to Feature #8243.

#27 Updated by johanbluecreek 2020-03-18 13:07:44

  • Status changed from Confirmed to In Progress

Applied in changeset commit:tails|7ae9112fa4e03d4331a5845b85e83d2108f491d6.

#28 Updated by intrigeri 2020-04-24 06:54:34

If someone starts working on this, it would be good if the design was Wayland-compatible: otherwise we would be increasing the amount of stuff we’ll soon need to port to Wayland (IOW: technical debt).