[tor-dev] bananaphone obfsproxy module
desnacked at riseup.net
Mon Nov 11 22:38:06 UTC 2013
David Stainton <dstainton415 at gmail.com> writes:
>> Looks fine!
>> BTW, does it work for you? Did you try the server-side using the
>> ServerTransportOptions torrc option (tor >= 0.2.5.1-alpha)?
> I have only tested it using the external mode.
> I've gotten obfsproxy + bananaphone to run with tor in managed mode;
> using the ServerTransportOptions... But I didn't test that it actually works.
> OK I'll try testing with tor >= 0.2.5.1-alpha using the ServerTransportOptions.
>> Some nitpicky comments:
>> - It doesn't really matter in this case but:
>> transport_class = transports.get_transport_class(transport, 'socks')
>> might be better as:
>> transport_class = transports.get_transport_class(transport, 'server')
>> in obfsproxy/managed/server.py.
> OK I will fix.
>> - I see you are passing 'None' to setup() when in external mode. Maybe
>> you can move the run_transport_setup() call to do_external_mode()
>> (after pt_config is instantiated), and then pass the pt_config to
>> setup(). This way external-mode transports can learn the state
>> location (it's in TransportConfig) during setup() (Scramblesuit
>> might like this).
>> If you do so, there is no reason to do
>> 'if transport_config is not None'
>> in obfsproxy/transports/bananaphone_transport.py.
>> - It would be nice if obfs2 also used the setup() method to set its
>> shared_secret. I'm referring to the block of code below:
>> # Check for shared-secret in the server transport options.
> OK I will do this... but can I do it all in my bananaphone branch or do you
> want the obfs2 change in another branch?
Please do it in your bananaphone branch if that's more convenient to
(If you want to be more adventurous, you can even make a new branch on
top of the current upstream master with your setup() function and the
obfs2 changes. I will merge that faster than the bananaphone changes.)
More information about the tor-dev