"socks_handshake: server asked for username/login auth but we were not provided any credentials"

[jkb]

A Tunnelblick user has reported [1] that he updated to OS X 10.7 ("Lion") and a new version of Tunnelblick which contains OpenVPN 2.2.1, and got the following error:

"socks_handshake: server asked for username/login auth but we were not provided any credentials"

When he patched Tunnelblick to use OpenVPN 2.1.4, his connection started working again.

This may be related to [2].

[1] (Requires a Google ID, so attached is a transcript of the report) ​https://groups.google.com/d/topic/tunnelblick-discuss/2q2g0IZ9bTM/discussion

[2] ​https://community.openvpn.net/openvpn/ticket/62

[jkb]

Transcript of thread on the Tunnelblick Discussion Group

[Samuli Seppänen]

Git logs for the 2.2 or 2.3 branches don't show any obvious changes since commit fc1fa9ffc7e3356458e ("Adding support for SOCKS plain text authentication").

Is this still an issue with latest 2.2 / 2.3 releases?

[Samuli Seppänen]

Can someone reproduce this on Git "master" or latest official release (atm 2.3.2)?

[Gert Döring]

OK, so the bug seems to be that we do not fall back to *not* send a username to the socks server, if none is configured, but fail with that error message.

I'm not sure I see a way to reproduce it, because it does *not* happen for my client setup with a socks proxy and no socks username (part of my regular t_client test rig).

Looking at the code in socks.c, this is a message that is triggered by the server asking for login credentials:

/* select the appropriate authentication method */
switch (buf[1])

{
case 0: /* no authentication */

break;

case 2: /* login/password */

if (!p->authfile[0])
{

msg(D_LINK_ERRORS, "socks_handshake: server asked for username/login auth but we were "

"not provided any credentials");

return false;

}

... so I'm not sure whether there is anything we can do here. If the server is asking for login/password, and we have none, this is the right message to print.

The code before that would just silently ignore the "buf[1]" byte from the server and go on - so if you have a server that a) asks for a username, but b) is fine with not receiving one in response, then that would trigger the message the user has seen.

OTOH in that case, just providing a bogus username should be good enough.

(Unless someone convinces me that our behaviour is the problem, instead of "the new code exhibits the configuration problem *elsewhere*", I'm going to close this in 4 weeks)

[Gert Döring]

Trac #377 sheds some more light on this (and thanks a lot :-) ) - it's an OpenVPN bug after all. We always advertise "we can do 'no auth' and 'username+password auth'" to the socks proxy, and if the socks proxy then comes back with "oh, hey, then I'd like to see your username+password!", we discover we don't have any, and panic...

The patch provided in #377 will change what we advertise depending on the availability of socks proxy credentials (eith "no auth" only, or "username+password" only), and if the server requests something that we did not offer, will complain with a more meaningful error message.

[Gert Döring]

Fix from #377 commited to master and release/2.3, will be part of OpenVPN 2.3.4.

commit 2903eba5dfe35c981329a833845e24de3882161a (master)
commit 34df13fdb65242b81c9006ee8ac83be4cc3f9e09 (release/2.3)

I think this ticket can now be closed. If the patch does not fix the issue, feel free to reopen.