ProxySOCKS5 proposes to the server to authenticate using user name and password, even if we don't have any.

[AlainKnaff]

Currently, ProxySOCKS5 proposes unconditionally proposes 2 authentications modes to the Socks server:

  buf[lIndex=index++] = 2;
  buf[index++] = 0; // NO AUTHENTICATION REQUIRED
  buf[index++] = 2; // USERNAME/PASSWORD

no matter whether a username and password has been set or not.

With most servers, this is not a problem, as they won't request username/password if no compulsory authentication has been configured on their side, even if the client proposes it.

However, https://f-droid.org/packages/pan.alexander.tordnscrypt.stable/ does take the client up on its offer,even though it would not otherwise need username and password.

With the result that the client fails a couple of lines later:
case 2: // USERNAME/PASSWORD
if (user == null || passwd == null)
break;

If I don't offer USERNAME/PASSWORD if none is supplied, all is ok:

  int lIndex;
  buf[lIndex=index++] = 2;
  buf[index++] = 0; // NO AUTHENTICATION REQUIRED
  if(user != null && passwd != null)
    buf[index++] = 2; // USERNAME/PASSWORD
  buf[lIndex] = (byte) (index - lIndex - 1);
  out.write(buf, 0, index);

Other thing: the exception raised if the above condition happens just says "fail in SOCKS5 proxy", which is a little bit vague, and also ambiguous, because it might happen in 2 different circumstances:

1. the one described above. => "SOCKS Server requires username/password, but none configured"
2. if ever the server picks an authentication mechanism which hasn't been offered. => "SOCKS5: Auth mode "+((buf[1]) & 0xff)+" not supported"

Thanks,

Alain

[norrisjeremy]

Hi @AlainKnaff,

Can you propose a PR to resolve the issue you are experiencing?

Thanks,
Jeremy

[norrisjeremy]

Hi @AlainKnaff,

Actually, can you take a look at #1007 and see if it addresses the problem you have reported?

Thanks!
Jeremy

[AlainKnaff]

Thanks for your quick reaction.

Yes, #1007 does indeed solve the main issue, thanks.

However, I'm wondering how future proof it is, in case support for the a 3rd authentication mechanism (GSSAPI) is ever introduced.

Moreover, the vagueness of the exception is not addressed (it's always "fail in SOCKS5 proxy") if ever it still occurs (in case server answers with a non-offered mechanism)

[norrisjeremy]

Hi @AlainKnaff,

It's probably extremely unlikely that we'll ever get GSSAPI support, unless someone contributes it.
And if we do, we can refactor the code at that time to better support it.

I'll try to review the exception some more and see if there's anything we can do to help improve the message to better communicate the failure.

Thanks,
Jeremy

[AlainKnaff]

I'm a bit puzzled however. What's actually wrong with my suggestions?

[norrisjeremy]

Hi @AlainKnaff,

Can you take a look at #1007 again and see if this addresses the problem you have reported.

Thanks,
Jeremy

[AlainKnaff]

Yeah, looks much better now, thanks. Even the case of non-zero status returned after authentication is covered, which I had forgotten.