Update Obfsproxy Tor Browser Bundles

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 (closed)), 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.

added component::archived/obfsproxy owner::sebastian priority::immediate resolution::fixed severity::normal status::closed type::defect labels

Trac:
Cc: N/A to sebastian

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

Trac:
Cc: sebastian to sebastian, erinn

Nobody is, but I made it my task.

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

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 don't care. Feel free to do something smart.

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

Done. Thanks for the link, asn.

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

Trac:
Cc: sebastian, erinn to N/A
Owner: asn to sebastian
Status: new to assigned

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.

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

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.

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

Set all tickets without a severity to "Normal"

Trac:
Severity: N/A to Normal

closed

mentioned in issue #6045 (moved)