Re: [tor-dev] bananaphone obfsproxy module

[David Stainton <dstainton415@xxxxxxxxx>]

George,

Thanks for the info!

This should approximate your suggestion:
https://github.com/david415/obfsproxy/tree/david-bananaphone-managed

Let me know your suggestions for improvement.
Either way I'll work on this more soon.


Onward!

David


On Sun, Nov 10, 2013 at 3:21 AM, George Kadianakis <desnacked@xxxxxxxxxx> wrote:
> David Stainton <dstainton415@xxxxxxxxx> writes:
>
>> Hi,
>>
>> Yeah... I should add a doc string to the BaseTransport __init__
>> explaining that it runs upon connect.
>>
>> OK yesterday I implemented transport class method called setup()...
>> The BananaphoneTransport overrides setup()... storing the markov model
>> in a class attribute.
>> I had to modify pyobfsproxy.py and run the class setup() method after
>> the external cli args are parsed.
>>
>> I made it work for external cli mode... by making pyobfsproxy.py run
>> the setup method for each transport after
>> args.validation_function(args) runs... because the setup method needs
>> some args to read the corpus file and build the markov model.
>>
>> What should I do to get arguments passed to obfsproxy when running in
>> managed mode?
>>
>
> Hm. Good question.
>
> You probably want to go to obfsproxy/managed/server.py and
> obfsproxy/managed/client.py and place a strategic
> run_transport_setup() hook. I would place it before the
> launch_transport_listener() call. You might also need to use
> obfsproxy/transports/get_transport_class() somewhere in there.
>
> Another nice thing would be if you could pass the pt_config struct in
> setup(), so that transports can use pt_config elements during
> initialization. As an example, see how obfs2 configures its
> shared-secret in its __init__ using getServerTransportOptions(). That
> could be done in its setup(), I think.
>
> Does this make sense? If you don't want to do this coding, I can do it
> at some point next week.
>
> Cheers!
>
> (
> And while I'm on it, let me tell you about the different ways that you
> can pass parameters to obfsproxy. I wanted to document this somewhere,
> and this thread seems like a good excuse :)
>
> - External mode:
>   You can pass global parameters to external mode transports by using
>   the register_external_mode_cli() and validate_external_mode_cli()
>   functions.
>
> - Managed mode:
>   - Global parameters:
>     These are parameters that are passed to obfsproxy on startup.
>
>     - Server:
>       On the server-side we can pass global parameters to obfsproxy by
>       using the TOR_PT_SERVER_TRANSPORT_OPTIONS environment
>       variable. Obfsproxy exposes those parameters using the
>       transport_config struct and
>       obfsproxy/common/transport_config.py:getServerTransportOptions .
>     - 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.
>
>   - Per-connection parameters:
>     These are parameters which are supposed to be different for each
>     connection. An example of such a parameter can be a shared-secret
>     used for a specific bridge connection.
>
>     - Server:
>       On the server-side we don't have a way to pass per-connection
>       parameters at the moment.
>     - Client:
>       On the client-side we pass per-connection parameters using the
>       SOCKS handshake as a covert channel. Transports can retrieve these
>       parameters using the handle_socks_args() method.
> )
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev