Skip to content
Snippets Groups Projects
New look: Off

Replace TBB with pluggable transports TBB

    • Closed Issue created by Andrew Lewman @andrew

    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?

    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    • Andrew Lewman added component::applications/tor bundles/installation flashproxy owner::erinn priority::medium resolution::fixed status::closed type::project labels

      added component::applications/tor bundles/installation flashproxy owner::erinn priority::medium resolution::fixed status::closed type::project labels

    • A
      Andrew Lewman @andrew ·
      Author

      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.

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

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

      4. 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)

      5. 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?

      6. We need a controller that supports obfs bridge requests to bridges.tpo

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

    • Roger Dingledine
      Roger Dingledine @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 (moved) (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.

    • D
      David Fifield @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 (moved).)
      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.
    • R
      Runa Sandvik @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.

    • D
      David Fifield @dcf ·

      Trac:
      Keywords: N/A deleted, flashproxy added

    • P
      proper @proper ·

      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 (moved) (gitweb).

      Trac:
      Cc: N/A to adrelanos@riseup.net

    • P
      proper @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 (moved)) 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".

    • D
      David Fifield @dcf ·

      Trac:
      Summary: Replace TBB with flashproxy/obfsproxy TBB to Replace TBB with pluggable transports TBB

    • D
      David Fifield @dcf ·

      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 (moved).)
      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.

      Trac:
      Status: new to closed
      Resolution: N/A to fixed

    • Trac closed

      closed

    • David Fifield mentioned in issue #8645 (moved)

      mentioned in issue #8645 (moved)

    Please register or sign in to reply