[tor-dev] bananaphone obfsproxy module

[David Stainton]

Hi Isis, George,

I think the Bananaphone transport might need another modification to
the obfsproxy api.
Isis pointed out that we really don't want to pass the corpus filename via
ServerTransportOptions... but instead only read it via optparse'ed commandline.
Actually I think the encodingSpec is the only Bananaphone options that
needs to get passed to the bridge database.

I cannot use register_external_mode_cli for this purpose because we want
to run obfsproxy in managed mode with tor...

So should I create another stub method for BaseTransport that can be
overridden...
it could be used to register managed-mode cli arg parser... which
populates class attributes of the transport.

What do you think?

David


On Thu, Nov 14, 2013 at 1:23 PM, George Kadianakis <desnacked at riseup.net> wrote:
> David Stainton <dstainton415 at gmail.com> writes:
>
>> Yeah obfs2 works perfectly... in managed mode passing the shared secret.
>> I'd love to contribute some documentation or demonstrate example
>> usage of obfsproxy... Shouldn't we setup a wiki for this purpose?
>>
>
> Then I should introduce you to:
> https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports
> Only a few days ago I added the bananaphone transport to that wiki
> page.  Feel free to contribute!
>
> BTW, it's definitely the case that obfsproxy (and the whole pluggable
> transport space) would benefit from more/better documentation. (As an
> example, I've been meaning to make a wiki page for the pluggable
> transport combiner that is currently in the works (#7167, #9744,
> #10061), but I haven't got to it yet.)
>
>> And finally I tested obfsproxy in managed mode with the bananaphone
>> transport... and it works!
>> It's laggy... but it works ;-)
>>
>
> Excellent news!
>
>> It's interesting to note that I got a couple of these in my client side tor log:
>>
>> Nov 14 20:17:16.000 [warn] Your Guard xxx ($xxx) is failing a very
>> large amount of circuits. Most likely this means the Tor network is
>> overloaded, but it could also mean an attack against you or
>> potentially the guard itself. Success counts are 56/184. Use counts
>> are 8/8. 176 circuits completed, 0 were unusable, 120 collapsed, and
>> 14 timed out. For reference, your timeout cutoff is 60 seconds.
>>
>> Also I tested and was able to pass transport options to obfsproxy
>> bananaphone and that works now that I fixed the BananaphoneTransport
>> setup method.
>>
>>
>> Onward!
>>
>> David
>>
>>
>> On Thu, Nov 14, 2013 at 1:12 AM, George Kadianakis <desnacked at riseup.net> wrote:
>>> David Stainton <dstainton415 at gmail.com> writes:
>>>
>>>> OK I tested obfsproxy obfs2 in managed mode with tor and it works...
>>>> But I guess that doesn't really test my changes since I'd have to pass
>>>> it a shared_secret
>>>>
>>>> """ - Client:
>>>>       On the client-side we don't have a way to pass global parameters
>>>>       to obfsproxy yet. If we ever need to, we can do it with
>>>>       environment variables here too. """
>>>>
>>>> Are you saying that we cannot use a shared secret with obfs2 in
>>>> managed mode with Tor?
>>>>
>>>
>>> No, it is possible.
>>>
>>> You just need to use the k=v parameters of the Bridge line in your
>>> torrc. These will be passed as per-connection parameters during the
>>> SOCKS handshake from Tor to obfsproxy. In obfsproxy, the parameters
>>> will be passed to your transport using handle_socks_args().
>>>