[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Orbot v14 alpha: obfsclient, Tor

Nathan Freitas <nathan@xxxxxxxxxxx> writes:

> On May 3, 2014 4:18:28 PM EDT, George Kadianakis <desnacked@xxxxxxxxxx> wrote:
>>George Kadianakis <desnacked@xxxxxxxxxx> writes:
>>> Nathan Freitas <nathan@xxxxxxxxxxx> writes:
>>>> On May 3, 2014 6:10:58 AM EDT, George Kadianakis
>><desnacked@xxxxxxxxxx> wrote:
>>>>>Nathan Freitas <nathan@xxxxxxxxxxx> writes:
>>>>>> Orbot now supports Obfs3 and Scramblesuit, thanks to Yawning's
>>>>>Great news! Thanks!
>>>>>BTW, how are obfs3 bridges supposed to be used?
>>>> This is the string I use for scramblesuit, copied directly from the
>>bridges.tp.o page:
>>>> scramblesuit xxx.xxx.xxx.xxx:xxxxx fingerprintxxx
>>>>>I installed Orbot-v14.0.0-ALPHA-2a.apk and checked the Preferences
>>>>>menu. There used to be an option called 'Obfuscated Bridges' that
>>>>>not there anymore. I assumed that I just have to specify a bridge,
>>>>>then prefix it with the transport name, like you do in the torrc.
>>>> Yes.
>>>>>So I clicked on 'Bridges' and then inserted 'obfs3 <ip>:<port>'
>>>>>my own <ip> and <port>) and started up Orbot. Unfortunately, I think
>>>>>that it didn't work very well. In the logs I got:
>>>>>Adding bridge: obfs3 <ip>:<port>
>>>> Hmm.... Add a fingerprint perhaps?
>>> Hm, I just tried that bridge again (without adding a fingerprint),
>>> now I'm getting the usual PT error:
>>> "We were supposed to connect to bridge '<ip>:<port>' using pluggable
>>> transport 'obfs3', but we can't find a pluggable transport proxy
>>> supporting 'obfs2'. ..."
>>> I'm not sure why I'm getting this today instead of the error I was
>>> getting yesterday [0]. I don't remember rebooting or changing
>>> anything.
>>> In any case, this new message usually means that obfsproxy crashed
>>> early: before being configured to be a Pluggable Transport. The same
>>> should be true for obfsclient too. Could it be a permission issue?
>>We played a bit with Yawning on this.
>>Are we sure that the ClientTransportPlugin is even set at all?
>>Because looking at
>>it seems that it depends on the boolean PREF_BRIDGES_OBFUSCATED which
>>apparently is never set since commit 147b57af4.
>>This seems to agree with my experience since I'm getting the log
>>message "Using standard bridges" which is on the 'else' codepath.
>>Or maybe we are missing something.
> Wow, I just realized that I removed that preference UI, but on my test device it was already set to TRUE, since I did not do a clean install.
> Thanks for the testing, and will push a new release our in next 24 hours with that fixed.


BTW, I'd suggest to parse the Bridge lines to figure out if PTs are
used and only then insert a ClientTransportPlugin line (in contrast,
to always adding a ClientTransportPlugin line). That's to avoid issues
like #11658.

You can check if a Bridge line uses PTs, by checking if its second
element is a C-identifier as the pt-spec.txt suggests. An IP:PORT is
not a C-identifier because of the colon.
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to