Project

General

Profile

Feature #15331

Support automatic bridge retrieval in Tor Launcher (Moat)

Added by intrigeri over 1 year ago. Updated 16 days ago.

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

10%

Feature Branch:
wip/feature/15331-moat
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Tor Launcher

Description

#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)


Related issues

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

Associated revisions

Revision f7e7c98e (diff)
Added by anonym over 1 year ago

Install Tor Browser 8.0a1 (moat-2018-02-15).

Let's start working on Moat-integration in Tails.

Refs: #15331

Revision f62ad368 (diff)
Added by intrigeri about 1 month ago

Adjust Moat prefs extraction to paths used in current Tor Browser (refs: #15331).

And in passing, escape "." in the regexp, split an overly long line,
and avoid referencing the ticket about Meek while this is about Moat.

Revision d1d0f392 (diff)
Added by intrigeri about 1 month ago

Add explanatory comment (refs: #15331).

Revision c331c6a4 (diff)
Added by intrigeri about 1 month ago

Create directory needed for Moat (refs: #15331)

Revision 384f2bc5 (diff)
Added by intrigeri about 1 month ago

Use the real meek for Moat (refs: #15331)

History

#1 Updated by intrigeri over 1 year ago

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

#2 Updated by intrigeri over 1 year ago

#3 Updated by intrigeri over 1 year ago

#4 Updated by intrigeri over 1 year ago

#5 Updated by intrigeri over 1 year ago

  • 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 over 1 year ago

  • 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 #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 #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 over 1 year ago

  • 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 over 1 year ago

  • Status changed from Confirmed to In Progress

Applied in changeset commit:fe08b248a1fc52271c027afc59b0945bb70ff26c.

#9 Updated by anonym over 1 year ago

  • % 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 over 1 year ago

#11 Updated by intrigeri over 1 year ago

#12 Updated by intrigeri over 1 year ago

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

#13 Updated by intrigeri over 1 year ago

#14 Updated by intrigeri over 1 year ago

#15 Updated by intrigeri over 1 year ago

#16 Updated by intrigeri over 1 year ago

  • 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 about 1 year ago

Tor Browser 8 was released with Moat support.

#18 Updated by sajolida 12 months ago

  • Description updated (diff)

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

#19 Updated by intrigeri 6 months ago

  • Status changed from In Progress to Confirmed

#20 Updated by intrigeri about 1 month ago

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

#21 Updated by intrigeri about 1 month ago

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 about 1 month ago

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

#23 Updated by intrigeri about 1 month ago

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

#24 Updated by intrigeri about 1 month ago

  • Status changed from Confirmed to In Progress

#25 Updated by intrigeri about 1 month ago

  • 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 16 days ago

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 #8243.

Also available in: Atom PDF