Support basic socks5 authentication

[jieyu]

This is for security reason. Socks5 supports username/password based authentication (https://tools.ietf.org/html/rfc1929).

In certain environment, we want to make sure only authenticated user can access the socks5 proxy (our case is in the reverse tunnel case, where the socks5 proxy server is running at the server side).

[jpillora]

It’s not supported on purpose since chisel has its own auth. Exposing socks options is a slippery slope. If you want a more socks features, I’d suggest running a separate socks server and point your tunnels there

On Tue, 4 Aug 2020 at 7:43 am Jie Yu notifications@github.com wrote:

This is for security reason. Socks5 supports username/password based authentication (https://tools.ietf.org/html/rfc1929).

In certain environment, we want to make sure only authenticated user can access the socks5 proxy (our case is in the reverse tunnel case, where the socks5 proxy server is running at the server side).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jpillora/chisel/issues/180, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE2X43VFW6O3YQWFORMHWDR64VPVANCNFSM4PTX5ZQQ .

[jieyu]

@jpillora the nice thing about the R:socks option is that the chisel client does not have to hard code the mapping information:

chisel server --reverse

chisel client <server_address> R:socks

The client on the server host can access hosts in the chisel client's network without requiring chisel client to configure the host:port mapping information for each service in the chisel client's network that we want to expose.

curl -x socks5h://localhost:1080 https://some.service.in.chisel.client.network/

I am curious to know why you think "expose socks options is a slippery slope"? Thanks again for your quick reply.

The feature we're looking for is to secure the socks5 proxy endpoint so that only authenticated client can use it:

curl -x socks5h://username:password@localhost:1080 https://some.service.in.chisel.client.network/

[jpillora]

Basically, if we put one SOCKS configuration option into chisel, then why not two? three? all possible SOCKS options? It adds complexity that I don't really want to include

Can you use chisel server --auth "user:pass" and chisel client --auth "user:pass" instead?

On Tue, 4 Aug 2020 at 08:23, Jie Yu notifications@github.com wrote:

@jpillora https://github.com/jpillora the nice thing about the R:socks option is that the chisel client does not have to hard code the mapping information:

chisel server --reverse

chisel client R:socks

The client on the server host can access hosts in the chisel client's network without requiring chisel client to configure the host:port mapping information for each service in the chisel client's network that we want to expose.

curl -x socks5h://localhost:1080 https://some.service.in.chisel.client.network/

I am curious to know why you think "expose socks options is a slippery slope"? Thanks again for your quick reply.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jpillora/chisel/issues/180#issuecomment-668270580, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE2X44A7TYSFTLEOVR4ZQDR642GRANCNFSM4PTX5ZQQ .

[jieyu]

Can you use chisel server --auth "user:pass" and chisel client --auth "user:pass" instead?

The authn you mentioned here is the authentication between chisel client and chisel server. The authn i was referring to was the authn between the client that's using the reverse tunnel (e.g., curl), and the socks5 proxy.

I understand your concerns on complexity.

[jpillora]

The authn i was referring to was the authn between the client that's using the reverse tunnel (e.g., curl), and the socks5 proxy.

So your "users" connect to your chisel client? If this is case, I'd suggest writing a small program using https://github.com/armon/go-socks5 (what chisel uses) to add the SOCKS features you need

[ezbik]

The authn i was referring to was the authn between the client that's using the reverse tunnel (e.g., curl), and the socks5 proxy.

Then use Gost instead, with mwss:// ( multiplexed websockets secure ). Gost server is more\less the same as Chisel server. Gost client can act as socks server with authentiaction.

[hectorj2f]

@jpillora I am continuing the work related to this topic.

So your "users" connect to your chisel client? If this is case, I'd suggest writing a small program using https://github.com/armon/go-socks5 (what chisel uses) to add the SOCKS features you need

To answer your question, yes. We have clients that talks to https://some.service.in.chisel.client.network/ so we need some authn that could be handled by the socks5 proxy.

[marcino239]

Hi @hectorj2f @jpillora - I've created a PR to address above issues. Hope you find them usefull