Opened 6 years ago

Closed 3 years ago

#8490 closed task (invalid)

Package and provide Pyobfsproxy bridge bundle

Reported by: bastik Owned by: erinn
Priority: Medium Milestone:
Component: Applications/Tor bundles/installation Version:
Severity: Normal Keywords: needs-triage
Cc: asn, dcf Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Currently there are separate bundles for being a bridge, relay and exit.

There is however no bundle for bridges with pluggable transport. I'd like to have an bundle with pyobsproxy/flashproxy transports while being a bridge.

I'd like a bundle for Windows, but don't want to exclude others. (Package what you can.) If anyone things it requires separate tickets I'll create them, and call this the parent.

Those bundles should help to aid the need for obfs3 capable bridges. Being able to understand Flashproxy shouldn't hurt.

Child Tickets

Change History (6)

comment:1 Changed 6 years ago by arma

Cc: asn dcf added

Sounds like changing the bridge bundles to include an obfsproxy by default is a wise plan.

I don't think it makes sense to put a flash proxy "server" in the bridge bundles though, right?

comment:2 in reply to:  1 Changed 6 years ago by dcf

Replying to arma:

Sounds like changing the bridge bundles to include an obfsproxy by default is a wise plan.

I don't think it makes sense to put a flash proxy "server" in the bridge bundles though, right?

I agree it sounds good for bridge bundles to include obfsproxy by default.

The flash proxy server is https://gitweb.torproject.org/flashproxy.git/tree/HEAD:/websocket-transport websocket-server. It doesn't make sense to put that in a bridge bundle because we don't need lots of websocket bridges at different addresses they way we do with obfsproxy. (The browser proxies take care of the "different addresses" part.) The websocket bridges won't even be used unless the facilitator knows about them.

(Aside: The websocket transport could be used apart from flash proxies as a super-cheapo obfuscator. The WebSocket framing would offset the bytes and maybe fool some pattern filters, also you could use the base64 WebSocket encoding. We're not shipping a websocket-client that works without flash proxies, though.)

comment:3 Changed 6 years ago by bastik

Summary: Package and provide Pyobfsproxy/Flashproxy bridge bundlePackage and provide Pyobfsproxy bridge bundle

The main reason was to spread obfs3 (as it was/is not available on a wide scale).

The reason to include the Flash proxy server part was to increase the possible connections a Flash proxy can make, which does not apply if the facilitator can't learn them from BridgeDB (what I never planned to have that). Including the Flash proxy server part and letting the facilitator hand out addresses would be harmful as an adversary could learn many if not all bridge addresses.

As long as there is no other transport that uses WebSockets it might be better to leave it out.

I changed the Summary accordingly.

comment:4 Changed 6 years ago by asn

Python-obfsproxy bridge bundles would be fun, I guess.

There used to be some C-obfsproxy bridge bundles floating around, but I'm not sure where they can be found anymore or if they saw much use. The Vidalia Pluggable Transport interface (#6729, #6412) needed more work to be actually useful.

I think that Erinn is still trying to package Python-obfsproxy to the normal client bundles. Maybe after she does so, it will be easier for her to incorporate Python-obfsproxy to the bridge bundles too... I don't know.

comment:5 Changed 5 years ago by erinn

Keywords: needs-triage added

comment:6 Changed 3 years ago by bastik

Resolution: invalid
Severity: Normal
Status: newclosed

There are no Windows bundles anymore, so this idea became invalid.

Note: See TracTickets for help on using tickets.