SOCKS5 CONNECTION_NOT_ALLOWED issue

[r-voland]

Hi!
I am observing strange behavior when connecting with username/password via a SOCKS5 proxy.
The connection to some proxy servers is fine, but when I try to connect to other servers, I get an error CONNECTION_NOT_ALLOWED.

I am always using standard connection method:

private SocketFactory getSocksSocketFactory() { final InetSocketAddress address = new InetSocketAddress(request.proxyIp, Integer.parseInt(request.proxyPort)); final AuthenticationCredentials credentials = getCredentials(); final BrokerConfiguration configuration = new StandardBrokerConfiguration(SOCKS5, address, credentials); final SocketFactory defaultSocketFactory = SocketFactory.getDefault(); return new BrokeredSocketFactory(configuration, defaultSocketFactory); }

Trace is:
Caused by: java.net.ConnectException: SOCKS Connect Request Failed: [CONNECTION_NOT_ALLOWED] Status [2] at com.exceptionfactory.socketbroker.protocol.socks.Socks5SocketBroker.connect(Socks5SocketBroker.java:95) at com.exceptionfactory.socketbroker.BrokeredSocket.connect(BrokeredSocket.java:103)

Please tell me where is the problem?

[r-voland]

It seems like has relations with using DNS through the SOCKS. Like curl --socks5-hostname option.
I was noticed that
curl --socks5 username:userpassword@proxy_ip:proxy:port http://example.com
get error (2)

but:
curl --socks5-hostname username:userpassword@proxy_ip:proxy:port http://example.com
works fine.

[exceptionfactory]

Thanks for describing the issue and different behavior @r-voland.

When Socket Broker encodes the SOCKS5 proxy connection request, it checks whether the InetSocketAddress is resolved. If the address is unresolved, it creates a DNS connection request and uses InetSocketAddress.getHostString(). If the address is resolved, it uses InetSocketAddress.getAddress().

In this scenario, if you want to force the use of the DNS address, instead of the resolved IP address, use InetSocketAddress.createUnresolved() with the DNS name and port number.

[r-voland]

Fixing it!
Just in file: com.exceptionfactory.socketbroker.protocol.socks.SocksRequestEncoder

replace:
`
final InetSocketAddress socketAddress = request.getSocketAddress();

    final InetAddress destinationAddress = socketAddress.getAddress();

    if (socketAddress.isUnresolved()) {      

        outputStream.write(SocksAddressType.DOMAIN_NAME.getCode());

`

to
`
final InetSocketAddress socketAddress = request.getSocketAddress();

    final InetAddress destinationAddress = socketAddress.getAddress();

    //if (socketAddress.isUnresolved()) {

    if (socketAddress != null) {

        outputStream.write(SocksAddressType.DOMAIN_NAME.getCode());

`
At date the hostname allways will sent to the server side, and then will be resolved to IP address.

It's works fine for Me.

[r-voland]

Thanks for describing the issue and different behavior @r-voland.

When Socket Broker encodes the SOCKS5 proxy connection request, it checks whether the InetSocketAddress is resolved. If the address is unresolved, it creates a DNS connection request and uses InetSocketAddress.getHostString(). If the address is resolved, it uses InetSocketAddress.getAddress().

In this scenario, if you want to force the use of the DNS address, instead of the resolved IP address, use InetSocketAddress.createUnresolved() with the DNS name and port number.

I think it should be possible to force the hostname to be sent to the server so that it is resolved there and not locally. In my case, for example, the hostname was resolved locally to the wrong IP address (not to be unresolved). And on the server - was resolved in the correct one. Therefore, it would be good to send hostname to the server without finding out whether the name was resolved locally or not. This is exactly what the --socks5-hostname parameter does in curl.

[exceptionfactory]

Are you able to control the construction of the InetSocketAddress that gets passed to the SocketFactory? If so, using InetSocketAddress.createUnresolved() would work.

[r-voland]

In fact, it turned out that being able to choose the location where the hostname will be resolved is quite important.
Now I have time to think about everything, and I want to offer you the following solution for Java:

Create a new HostnameResolvingPolicy class, and in it an Enum of :

HostnameResolvingPolicy.Standard - first locally, and if it didn't work out, then on the server;
HostnameResolvingPolicy.Local - only locally. If it didn't work out, generate an error
HostnameResolvingPolicy.Server - only on the server.

Using such an class will make the code better readable and understandable.
Of course, this is my personal opinion.)
Good luck!

[exceptionfactory]

Thanks for the reply and suggestion @r-voland.

During the initial implementation, I considered something along the lines of the resolution policy described. Instead of introducing a configuration option, however, I opted to follow the pattern of the JDK SocksSocketImpl, which uses InetSocketAddress.isUnresolved() to determine whether to send the request as a Domain Name.

The downside is that this behavior is not necessarily intuitive, which gets back to some policy-based approach. This could be added to the BrokerConfiguration, retaining the existing behavior, but providing other options.

At the moment, however, it seems better to add some documentation around the current behavior, which still allows the caller to make hostname resolution decisions. If there are libraries that don't provide direct control of InetSocketAddress construction, that may be a reason to consider the policy option.

If you have a public example of where this new policy is necessary, versus changing the InetSocketAddress construction, that would be a helpful point of consideration.