[tor-dev] Combining obfsproxy+scramblesuit with OpenVPN

[Yawning Angel]

On Mon, 10 Mar 2014 03:27:12 +0200
irregulator at riseup.net wrote:

> Are we sure it's an OpenVPN bug? Cause I'm getting a :
> 
> "socks_handshake: server asked for username/login auth but we were not
> provided any credentials"
> 
> which kind of makes sense regarding the methods' priority in socks5.py
> 
> And that occurs even when using obfs3 which shouldn't expect any
> credentials.
> 
> Am I missing something?

Right, this is illustrating that it is a OpenVPN bug.  So, what SOCKSv5
does is, when the client (OpenVPN) connects, it sends the version of the
SOCKS protocol (5) and a list of methods it is willing to use.  Out of
the list that is sent, the server (obfsproxy) picks the one.

I posted the snippet of code from OpenVPN that does this in my last
e-mail, but in more detail:

> >> const ssize_t size = send (sd, "\x05\x02\x00\x02", 4,
> >> MSG_NOSIGNAL);

0x05 -> I am speaking SOCKSv5
0x02 -> I have 2 authentication methods I can use
0x00 -> I can use NO AUTHENTICATION REQUIRED
0x02 -> I can use USERNAME/PASSWORD

This happens regardless of if the user specifies a username/password in
the config or not.

What should happen is:

 * If there is no username/password specified in the OpenVPN config, it
   sends 0x05 0x01 0x00 (I only support NO AUTHENTICATION REQUIRED)
 * If there is a username/password specified in the OpenVPN config, it
   sends 0x05 0x01 0x02 (I only support USERNAME/PASSWORD).

The SOCKS server I wrote will always pick USERNAME/PASSWORD over no
authentication if it is offered by the client (In this context
OpenVPN).  What your patch does is reverse this to always pick NO
AUTHENTICATION REQUIRED over USERNAME/PASSWORD, which will break things
for OpenVPN users that want to specify the ScrambleSuit shared secret
in the OpenVPN config file.

For what it's worth, the obfsproxy behavior currently present also
detects mis-configured clients (users inputting credentials when the
SOCKS server doesn't require any), so I think it is a saner default.

The relevant portions of RFC 1928 is:

  The NMETHODS field contains the number of method identifier octets
  that appear in the METHODS field.

  The server selects from one of the methods given in METHODS, and
  sends a METHOD selection message.

> Option 3 does work for scramblesuit, cool! :)
> 
> So, socks authentication could be used by the OpenVPN client to pass
> scramblesuit credentials to obfsproxy. Could I somehow run obfsproxy
> without explicitly setting a scramblesuit secret, as it's needed when
> running unmanaged?

The moment the OpenVPN people fix their broken SOCKS client to not
offer to negotiate an authentication method that they can't actually
use due to missing parameters, this will work as expected.

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140310/9f7d4bdf/attachment-0001.sig>