Opened 5 years ago

Closed 4 years ago

#8019 closed project (fixed)

Replace TBB with pluggable transports TBB

Reported by: phobos Owned by: erinn
Priority: Medium Milestone:
Component: Applications/Tor bundles/installation Version:
Severity: Keywords: flashproxy
Cc: adrelanos@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

It seems the arms race is progressing to the point where flashproxy and obfsproxy will be required globally in a future quickly approaching.

What does this mean for our build process, our translations, usability by users, and general upgrade/reliability of flashproxy and obfsproxy bridges/relays?

Child Tickets

Change History (9)

comment:1 Changed 5 years ago by phobos

Here are some initial thoughts:

  1. Tor QA/Build will have to sign the packages. Right now it's just alexandre, which few of us know.
  1. We'll need to update translations for (flash|obs)proxy. At a minimum, these languages should be available, https://www.torproject.org/projects/torbrowser.html.en#downloadtbb
  1. The current list of obfsproxy bridges will need to be larger, otherwise we're going to point millions of people at 12 bridges. Maybe instead, we don't actually ship with configured bridges, but leave the possibility that it's there.
  1. We need to replace the current bridge infrastructure with obfs/flash bridges (this is operationally into bridgeDB and currently deployed bridges need to be swapped with obfs/flash)
  1. Can all relays act as obfs/flash bridges by default as well? If tor works by talking to a relay, then no need for obfs, yes?
  1. We need a controller that supports obfs bridge requests to bridges.tpo
  1. we need to make this work with tor-stable (0.2.3,x) and not force the world into tor-alpha (0.2.4.x) all at once.

comment:2 Changed 5 years ago by arma

Oh. When I said "yes" to this idea, I meant "we should replace the obfsproxy tbb bundles with the flashproxy+obfsproxy tbb bundles". I did not yet mean "all tbb users should be using obfsproxy by default".

The current list of obfsproxy bridges will need to be larger, otherwise we're going to point millions of people at 12 bridges. Maybe instead, we don't actually ship with configured bridges, but leave the possibility that it's there.

There are a pile of tickets for features we need, like "don't launch the transport unless there's a bridge line that asked for it", that aren't in place yet.

Can all relays act as obfs/flash bridges by default as well? If tor works by talking to a relay, then no need for obfs, yes?

Relays can't even act as normal bridges. See #1776 (see also item 19 on SponsorF Year3)

we need to make this work with tor-stable (0.2.3,x) and not force the world into tor-alpha (0.2.4.x) all at once.

You will make most people jump up and down with this statement. Imo none of the 0.2.3 things should change. Probably none of the 0.2.4 things should change. In general, let's stop trying to look back and focus on looking forward.

comment:3 in reply to:  1 ; Changed 5 years ago by dcf

Replying to phobos:

  1. Tor QA/Build will have to sign the packages. Right now it's just alexandre, which few of us know.

I signed the packages too. For some reason GPG only checks the first signature, but there are two signatures in each of the .asc files. I signed Alexandre's packages after diffing them with my independently built packages.

  1. The current list of obfsproxy bridges will need to be larger, otherwise we're going to point millions of people at 12 bridges. Maybe instead, we don't actually ship with configured bridges, but leave the possibility that it's there.

The way I see this working out in the long term is,

  1. We make a separate PT bundle, having all known deployed and reasonable transports enabled by default. (Check, #7824.)
  2. We add new transports to the separate PT bundle as they become deployed and reasonable.
  3. We extend Vidalia in the PT bundle to allow selectively enabling and disabling each of the supported transports (think a panel of checkboxes).
  4. The PT bundle changes get folded back into the mainline TBB. The separate PT bundle doesn't exist anymore. The mainline TBB contains all known deployed and reasonable transports, disabled by default. Vidalia is able to enable each of them individually.

comment:4 in reply to:  1 ; Changed 5 years ago by runa

Replying to phobos:

  1. The current list of obfsproxy bridges will need to be larger, otherwise we're going to point millions of people at 12 bridges. Maybe instead, we don't actually ship with configured bridges, but leave the possibility that it's there.

We need to encourage more people to run obfsproxy bridges. Not shipping with configured bridges will be a support nightmare.

comment:5 Changed 5 years ago by dcf

Keywords: flashproxy added

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

Cc: adrelanos@… added

Replying to dcf:

We extend Vidalia in the PT bundle to allow selectively enabling and disabling each of the supported transports (think a panel of checkboxes).

It is my understanding, that Vidalia will be deprecated in favor of #6009 (gitweb).

comment:7 in reply to:  4 Changed 5 years ago by proper

Replying to runa:

Replying to phobos:

  1. The current list of obfsproxy bridges will need to be larger, otherwise we're going to point millions of people at 12 bridges. Maybe instead, we don't actually ship with configured bridges, but leave the possibility that it's there.

We need to encourage more people to run obfsproxy bridges. Not shipping with configured bridges will be a support nightmare.

I believe tor-launcher (which is a first time connection method wizard) (#6009) could solve that, by having some clever worded options for use cases like "connect to the public Tor network", "try the default bridges", "get semi-public bridges", "use private bridges", "configure for censorship circumvention", "configure for Tor traffic obfuscation".

comment:8 Changed 4 years ago by dcf

Summary: Replace TBB with flashproxy/obfsproxy TBBReplace TBB with pluggable transports TBB

comment:9 in reply to:  3 Changed 4 years ago by dcf

Resolution: fixed
Status: newclosed

Replying to dcf:

The way I see this working out in the long term is,

  1. We make a separate PT bundle, having all known deployed and reasonable transports enabled by default. (Check, #7824.)
  2. We add new transports to the separate PT bundle as they become deployed and reasonable.
  3. We extend Vidalia in the PT bundle to allow selectively enabling and disabling each of the supported transports (think a panel of checkboxes).
  4. The PT bundle changes get folded back into the mainline TBB. The separate PT bundle doesn't exist anymore. The mainline TBB contains all known deployed and reasonable transports, disabled by default. Vidalia is able to enable each of them individually.

These all look done with the 3.6 beta.

Note: See TracTickets for help on using tickets.