On Wed, 05 Mar 2014 15:08:06 +0200 irregulator@riseup.net wrote:
Luckily yawning provided a patch some days ago [5], and I decided to test it. According to patch's comments, it implements a Socks5 proxy with authentication as in RFC 1928/RFC 1929. This authentication is gonna serve as a means to pass parameters to the pluggable transport, please correct me on this one.
Correct.
Firstly, does this patch and generally obfsproxy development takes in consideration other clients except for Tor, e.g. OpenVPN or OpenSSH ? I think it would be very nice to have a way to combine OpenVPN with Scramblesuit as stated in the latter's paper. But then I'll understand if that's not a priority for obfsproxy's developers.
I didn't consider other things when I wrote it, though I expect it to work, assuming the "other things" implement SOCKSv5 correctly.
Also note that my github branch[0] will have a more up to date version of the code, there are a few changes that I have made based on feedback since then, and I'll probably change the code further.
At this point the only change that would be user facing is that I may allow the DOMAINNAME address type (which is a bad thing to support for pluggable transports, but probably useful for everyone else.
So, while testing OpenVPN with obfsproxy and the latest patch, the vpn client enters the authentication phase.
Yay.
Do the credentials depend on the pluggable transport in use by the obfsproxy?
Yes. It only should happen for obfs2 (if Shared Secret mode is used) and ScrambleSuit. All the other transports will ignore any credentials passed.
If so, what credentials should the vpn or the ssh socks client provide when talking with scramblesuit?
As the *username*: * "password=<Base32 encoded k_B>" k_B is 32 characters encoded.
As the *password*: * '\0' (A single byte of value 0x00).
Will vpn client have to provide the session ticket or other pre-shared secret through socks authentication?
Just k_B. Session Tickets are separate and not something the user should ever mess with.
It is also possible to skip using RFC 1929 auth entirely by passing "--password <Base32 encoded k_B>" as a command line option.
Regards,