[tor-dev] Combining obfsproxy+scramblesuit with OpenVPN

[Yawning Angel]

On Thu, 06 Mar 2014 19:22:16 +0200
irregulator <irregulator at riseup.net> wrote:
> On 03/05/2014 07:58 PM, Yawning Angel wrote:
> Hey people thanks for your input,
> 
> I'm actually passing password inline while starting obfsproxy
> (client-side) like that :
> 
> python pyobfsproxy.py --log-min-severity=info scramblesuit --password
> LLDNOWV7I4P6RKFJMDEMIY2GNU2IQISA socks 127.0.0.1:9999
> 
> Still when openvpn client connects to localhost:9999 enters the
> authentication phase. I think this is undesirable and needless since
> obfsproxy client has already been started with the password.

Looking at the OpenVPN source (src/openvpn/socks.c):

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

The method selection request is hardcoded to always claim support for
No Auth, and Username/Password Auth in that order.

This as a OpenVPN bug.  It should not be offering to negotiate
Username/Password Auth if the user has not provided credentials.  And,
if the user did happen to provide credentials, then it should not claim
that No Auth is acceptable.

> So I made a rearrangement like this :

[snip]

> After the change openVPN client is no more requested to enter
> credentials, and it works like a charm. OpenVPN client talks to
> OpenVPN server over scramblesuit :)
> 
> So I am wondering, is the change above acceptable for all cases? I
> mean, changing the priority between authentication and no
> authentication mode, will it affect some PTs ?

I explicitly wrote the code to prefer using auth when the client claims
to support it to guard against brain damaged clients that offer up No
Auth Required when the user provides a username/password (with your
code, the PT arguments get dropped, and this breaks for people that
wish to have OpenVPN pass k_B to obfsproxy), so I don't see this as a
workable fix since it just breaks the other way of doing it.

For Tor, this does not matter since it only claim authentication
support if authentication if PT args are given.

> I'm not sure what is better here : should the OpenVPN client pass the
> scramblesuit password to the obfsproxy client listening to localhost,
> or the should the obfsproxy client already know the password so as the
> OpenVPN client doesn't need to authenticate at all.

Not sure which is better.

> If the first is preferable, any idea how the '\0' value could fit in
> there? OpenVPN socks authentication is implemented, afaik, either via
> standard input or via a two line file containing user-password.

Options:

 * Ignore the PASSWD field if the UNAME field is less than 255
   characters.  This feels somewhat ugly, and has Nasty Surprise
   potential in the future.

 * Only treat the SOCKS auth as a username/password when obfsproxy is
   in managed mode.  This forces everyone to pass in args via the
   command line, and would break the "I want to use obfsproxy to
   connect to multiple servers via ScrambleSuit use case", so is
   probably unacceptable.

 * Leave things as is.  Since the UNAME/PASSWD fields are just
   concatenated (except for the case where the passwd is 1 NUL
   character, people can set the credentials to something like:

   Username: "password="
   Password: "<Base32 Encoded k_B here>"

   Sorry I should have been more clear about this.

Presently I am leaning toward option 3, but I don't feel too strongly
about this as long as Tor continues to work (Which it will regardless
of how this is resolved since it will always only request SOCKS auth
mechanisms that make sense based on the config file).

-- 
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/20140306/74eca32d/attachment-0001.sig>