Opened 9 years ago

Closed 6 years ago

#148 closed Bug / Defect (fixed)

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

Reported by: jkb Owned by:
Priority: minor Milestone:
Component: Generic / unclassified Version: OpenVPN 2.2.0 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: socks tunnelblick osx
Cc: jkbullard@…

Description

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

Attachments (1)

socks-discussion.txt (3.2 KB) - added by jkb 9 years ago.
Transcript of thread on the Tunnelblick Discussion Group

Download all attachments as: .zip

Change History (8)

Changed 9 years ago by jkb

Attachment: socks-discussion.txt added

Transcript of thread on the Tunnelblick Discussion Group

comment:1 Changed 7 years ago by 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?

comment:2 Changed 7 years ago by Samuli Seppänen

Keywords: tunnelblick osx added

comment:3 Changed 7 years ago by Samuli Seppänen

Priority: majorminor

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

comment:4 Changed 7 years ago by 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)

comment:5 Changed 6 years ago by 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.

comment:6 Changed 6 years ago by 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.

comment:7 Changed 6 years ago by Gert Döring

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.