Opened 8 years ago

Closed 8 years ago

#4927 closed task (fixed)

Prepare a Pluggable Transports Bundle

Reported by: asn Owned by: erinn
Priority: Medium Milestone:
Component: Applications/Tor bundles/installation Version:
Severity: Keywords:
Cc: arma, nickm, chiiph, erinn Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

This ticket is about preparing a Pluggable Transports Tor Bundle (PTTB, for now)that end users can download and run effortlessly.

Some thoughts on how the PTTB should look like:

Bridge-side

I imagine that a bridge-side PTTB will need a tor version that supports managed proxies, and contains the fix for #4725 and #4865.

I suppose that PTTB will contain an obfsproxy binary in its root directory, and then inside the premade torrc there will be a line that references and launches it with obfs2, like this:

ServerTransportPlugin obfs2 exec ../../obfsproxy --managed

Ideally then, Vidalia will pick up the log line (or even better we should export this information using the control protocol) that says in which port obfsproxy is listening, and display it to the bridge operator so that he can give it to his/her users. The log line currently looks like this:

 Registered server transport 'obfs2' at '0.0.0.0:42666'

Client-side

A client-side PTTB simply needs a tor version that supports managed proxies (over 0.2.3.10).

obfsproxy will again be placed in the root directory of PTTB (or somewhere around there), and the premade torrc should reference it with a ClientTransportPlugin line, like this:

ClientTransportPlugin obfs2 exec ../../obfsproxy --managed

Then, Vidalia should have some sort of graphical way of adding obfs2'ed bridges that end-users will do. Such bridge lines in torrc usually look like this:

Bridge obfs2 192.0.2.1:42666

BTW, I don't really know how TBB works internally, so my thoughts above might not be realistic.

I haven't opened any tickets about the things that must be implemented in Vidalia. I should do this.

Child Tickets

Change History (9)

comment:1 Changed 8 years ago by asn

Type: defecttask

comment:2 Changed 8 years ago by chiiph

The Client-side part is already done in the soon to come Vidalias (0.2.16 and 0.3.1-alpha). The user can just add "obfs2 192.0.2.1:42666" as he/she adds a regular bridge and Vidalia will just pass that to tor. As long as we provide a the correct torrc, it will work.

The Bridge-size can be implemented as a plugin. From the Vidalia side, it'd be good to have a control command to consult transport status somehow, in which case it should be easy to create a "transport status plugin".

comment:3 in reply to:  2 ; Changed 8 years ago by asn

Replying to chiiph:

The Client-side part is already done in the soon to come Vidalias (0.2.16 and 0.3.1-alpha). The user can just add "obfs2 192.0.2.1:42666" as he/she adds a regular bridge and Vidalia will just pass that to tor. As long as we provide a the correct torrc, it will work.

Great!
(Have you tried it?)

The Bridge-size can be implemented as a plugin. From the Vidalia side, it'd be good to have a control command to consult transport status somehow, in which case it should be easy to create a "transport status plugin".

It seems to me that it's time for an "Expose pluggable transport information to the control port" ticket. I'll create it soon.

comment:4 in reply to:  3 Changed 8 years ago by chiiph

Replying to asn:

Replying to chiiph:

The Client-side part is already done in the soon to come Vidalias (0.2.16 and 0.3.1-alpha). The user can just add "obfs2 192.0.2.1:42666" as he/she adds a regular bridge and Vidalia will just pass that to tor. As long as we provide a the correct torrc, it will work.

Great!
(Have you tried it?)

Yes, I'm sure it works, I retested before that comment :)

The Bridge-size can be implemented as a plugin. From the Vidalia side, it'd be good to have a control command to consult transport status somehow, in which case it should be easy to create a "transport status plugin".

It seems to me that it's time for an "Expose pluggable transport information to the control port" ticket. I'll create it soon.

That would be nice, yes.

comment:5 Changed 8 years ago by asn

This is how I made a PTTB:

I took the current TBB off
https://www.torproject.org/download/download-easy.html.en:

I replaced ./App/tor with a tor-0.2.3.11.

I copied an obfsproxy binary to ./App/.

I added these lines in ./Data/Tor/torrc:

UseBridges 1
Bridge obfs2 192.0.2.1:42666
ClientTransportPlugin obfs2 exec ./App/obfsproxy --managed

Of course, 192.0.2.1:42666 was an actual obfs2'ed bridge address.

comment:6 in reply to:  5 ; Changed 8 years ago by rransom

Replying to asn:

This is how I made a PTTB:

I took the current TBB off
https://www.torproject.org/download/download-easy.html.en:

I replaced ./App/tor with a tor-0.2.3.11.

I copied an obfsproxy binary to ./App/.

I added these lines in ./Data/Tor/torrc:

UseBridges 1
Bridge obfs2 192.0.2.1:42666
ClientTransportPlugin obfs2 exec ./App/obfsproxy --managed

Of course, 192.0.2.1:42666 was an actual obfs2'ed bridge address.

This was on Linux; for Windows, we have an obfsproxy binary (thanks to Sebastian), we have Tor 0.2.3.10-alpha binaries in packages in www.tpo/dist/ , and we need someone to test this process.

comment:7 in reply to:  5 Changed 8 years ago by arma

Replying to asn:

I copied an obfsproxy binary to ./App/.

For the Linux TBB, I assume we'll want an obfsproxy binary that is statically built enough that the user doesn't need a system libevent2 installed, yes? Where are we on that?

comment:8 in reply to:  6 Changed 8 years ago by rransom

Replying to rransom:

Replying to asn:

This is how I made a PTTB:

I took the current TBB off
https://www.torproject.org/download/download-easy.html.en:

I replaced ./App/tor with a tor-0.2.3.11.

I copied an obfsproxy binary to ./App/.

I added these lines in ./Data/Tor/torrc:

UseBridges 1
Bridge obfs2 192.0.2.1:42666
ClientTransportPlugin obfs2 exec ./App/obfsproxy --managed

Of course, 192.0.2.1:42666 was an actual obfs2'ed bridge address.

This was on Linux; for Windows, we have an obfsproxy binary (thanks to Sebastian), we have Tor 0.2.3.10-alpha binaries in packages in www.tpo/dist/ , and we need someone to test this process.

IT WORKS!!! Microsoft's screwy incompatible APIs for spawning and controlling subprocesses couldn't stop us!

(I used Tor 0.2.3.10-alpha binaries from the ‘expert bundle’ tor-0.2.3.10-alpha-win32-1.exe , and I copied only Sebastian's obfsproxy.exe into the App/ directory because there was already a libeay32.dll there. The only change I made to asn's torrc lines was to use a real obfsproxy address; I didn't need to Windows-ize “./App/obfsproxy”.)

comment:9 Changed 8 years ago by asn

Resolution: fixed
Status: newclosed

We now have the know-how.

Note: See TracTickets for help on using tickets.