Opened 2 years ago

Closed 20 months ago

#5937 closed defect (fixed)

Update Obfsproxy Tor Browser Bundles

Reported by: runa Owned by: sebastian
Priority: blocker Milestone:
Component: Obfsproxy Version:
Keywords: Cc:
Actual Points: Parent ID:
Points:

Description

Earlier this month, we updated the normal Tor Browser Bundles to prevent WebSocket DNS leaks and we later upgraded to FF 12.0. We did nothing with the Obfsproxy Tor Browser Bundles.

The current version of the Obfsproxy Tor Browser Bundles (ver. 2.3.12-4) is shipped with FF 11.0, suffers from the WebSocket DNS leak bug (#5741), and probably a range of other bugs as well.

If we can't actively maintain the Obfsproxy Tor Browser Bundles, we should consider removing them completely.

Child Tickets

Change History (13)

comment:1 Changed 2 years ago by runa

  • Cc sebastian added

comment:2 Changed 2 years ago by runa

  • Cc erinn added

I'm not sure who's responsible for the Obfsproxy Tor Browser Bundles these days.

comment:3 Changed 2 years ago by Sebastian

Nobody is, but I made it my task.

comment:4 Changed 2 years ago by Sebastian

Ah, there was a hidden question. The problem is that I'm swamped with sponsor deliverables, plus it doesn't make sense to make a bundle if we know the next security update for tbb is already in the process of being created. So obfsproxy is a lower priority

comment:5 follow-up: Changed 2 years ago by runa

Should we take down https://www.torproject.org/projects/obfsproxy in the meantime, or at least update the page to let users know the current version is insecure and should not be used?

comment:6 Changed 2 years ago by Sebastian

I don't care. Feel free to do something smart.

comment:7 in reply to: ↑ 5 Changed 2 years ago by asn

Replying to runa:

Should we take down https://www.torproject.org/projects/obfsproxy in the meantime, or at least update the page to let users know the current version is insecure and should not be used?

I agree that we should either add a big fat warning in that page [0], or remove the download links entirely. I'm not sure which way is better.

Runa, can you push stuff to the webpage? Can you add a warning?

Thanks!

[0]: like, http://archives.seul.org/or/cvs/Apr-2012/msg00007.html

comment:8 Changed 2 years ago by runa

Done. Thanks for the link, asn.

comment:9 Changed 23 months ago by runa

Users in China, Iran, Kazakhstan, and (now) Ethiopia need the Obfsproxy Tor Browser Bundle to connect to Tor. When can we update the bundles?

comment:10 Changed 23 months ago by runa

  • Cc sebastian erinn removed
  • Owner changed from asn to sebastian
  • Status changed from new to assigned

comment:11 follow-up: Changed 21 months ago by phobos

Here's my radical proposal, obfsproxy bundles should not exist. obfsproxy should be an option inside the normal Tor Browser Bundle. After talking to asn about this, it seems the next steps are:

  1. Tor 0.2.3x needs to go stable
  2. TBB includes tor-0.2.3.x
  3. Vidalia needs some sort of obfsproxy switch.
  4. bridgedb needs to handle obfsproxy bridges (or all bridges need to be obfsproxy bridges by default).

Most of the problem is that our build and support people are overloaded, and building more bundles is just added pain and stress for selective gain.

comment:12 in reply to: ↑ 11 Changed 21 months ago by asn

Replying to phobos:

Here's my radical proposal, obfsproxy bundles should not exist. obfsproxy should be an option inside the normal Tor Browser Bundle. After talking to asn about this, it seems the next steps are:

  1. Tor 0.2.3x needs to go stable
  2. TBB includes tor-0.2.3.x
  3. Vidalia needs some sort of obfsproxy switch.
  4. bridgedb needs to handle obfsproxy bridges (or all bridges need to be obfsproxy bridges by default).

I find your radical proposal a good idea.

I was thinking of how Vidalia needs some sort of obfsproxy switch. should happen. Maybe when the My ISP blocks connections to the Tor network... Vidalia button is clicked, a ClientTransportPlugin line should be added to the config (or is this usually done through the control protocol? If so, then this has to be implemented in tor.git.).

At this point the user should be able to add new obfs2 bridges through Vidalia (which I think is implemented), and the user should be able to retrieve obfs2 bridges through bridgedb (#4568: implemented but not deployed yet).

Most of the problem is that our build and support people are overloaded, and building more bundles is just added pain and stress for selective gain.

True.

comment:13 Changed 20 months ago by Sebastian

  • Resolution set to fixed
  • Status changed from assigned to closed

I'm going to close this now, as we have obfsproxy bundles. The idea that phobos mentioned is what our plan is all along, and we'll set it into motion once 0.2.3 is stable.

Note: See TracTickets for help on using tickets.