sticnarf / tokio-socks

Asynchronous SOCKS proxy support for Rust.

tokio-socks

Asynchronous SOCKS proxy support for Rust.

Features

• CONNECT command
• BIND command
• ASSOCIATE command
• Username/password authentication
• GSSAPI authentication
• Asynchronous DNS resolution
• Chain proxies (see example)
• SOCKS4

Compatibility with Other Async Runtimes

By default, the tokio feature is enabled, as the crate name suggests.

Users can opt out tokio by setting default-features = false. The *_with_socket functions accept types implementing the AsyncSocket trait.

The crate provides io::Compat that implements AsyncSocket for futures-io types (requiring the futures-io feature).

License

This project is licensed under the MIT License - see the LICENSE file for details.

Acknowledgments

• sfackler/rust-socks

tokio-socks's Issues

Feature Request: SOCK4 support

Add support for socks4, under this crate.
Support for CONNECT and BIND.
Support for UserId included.

Feature Request: Socks5 Gssapi support.

Hey, have been using this as a default client lib for socks5 client connection. However, recently we wanted to add gssapi support over socks5. Is there any plan for it, I do have a crude implementation of the same, if there no plan in motion, I can put it up for PR and merge. @sticnarf

ConnectFuture buffer too small

ConnectFuture has a buffer size that is too small for username/password authentication. The username and password can each be up to 255 bytes and are written as part of the same message, but the buffer is only 262 bytes. I believe the buffer must be 513 bytes to account for the username + password + ver + ulen + plen

Feature request: SOCKS5 UDP support

SOCKS5 supports proxying UDP. It'd be nice if this library supported it.

Possible Buffer Overflow

tokio-socks/src/tcp.rs

Line 337 in 9fdcccc

self.buf[(2 + username_len)] = password_len as u8;

if the username len is 256, and so is the password, then it seems our buf won't have enough space to write all the data and we'll possibly panic.

We should make the buffer larger, or return an err if username/password is too long.

another option would be to make the buf heap allocated and growable

How to compile an executable program?

hi.

I don't know rust programming, but I have a rust compilation environment. I tried to use the command cargo build --release --no-default-features, but I didn't find the runnable service program I wanted. Can anyone tell me how to compile? Thanks. 😁

Kind Regards.

Remove Panic for unknown auth type

tokio-socks/src/tcp.rs

Line 425 in 9fdcccc

_ => unimplemented!(),

Panicking is not a great option here -- we should probably return an error instead.

TCP nodelay

I've noticed that using TCP nodelay allows SOCKS connections to be established more quickly because the SOCKS negotiation includes many small messages. I haven't tested using nodelay with this library in particular, but it would be nice to provide this configuration option so that the caller can determine whether they want to use nodelay.

In general, it might be easier to allow the library consumer to have more control over how the underlying TCP connection is configured. The easiest way to do this would probably be to support a variant of Socks5Stream::connect that takes an existing TCP stream so the caller can set up the stream however they want, but this could also be done with specific configuration options.

I can set up a PR for any of these options pretty quickly, but I wanted to discuss first.

Reading extra bytes when server returns connection error

Something I observed as a result of Reqwest using this crate under the hood. I'm interested in hearing the maintainer's thoughts on this, because I feel as though the spec isn't very specific here.

receive_reply reads 4 bytes with tcp.read_exact, but it's my interpretation of the spec that the server only needs to respond with 2 bytes: VER and REP. Only if REP is X'00' succeeded should the client anticipate RSV and ATYP.

Is my interpretation incorrect?

support for unix socket

For a personal project I need to connect to a local socks proxy through unix domain socket.
This is currently not supported by this crate, so I wanted to inquire if you were interested in supporting that, or if I should look for an other crate.
It could be done by allowing the end user to provide an AsyncRead+AsyncWrite, which would allow for this proposal to be implemented at the same time.

Too strict lifetimes

I am trying to implement very simple connection algo (stripped down example):

use futures::future::Future;

use futures::future::IntoFuture;
use std::net::SocketAddr;

fn main() {
    let proxy = std::env::args().nth(1).unwrap();
    let proxy = proxy.parse::<SocketAddr>().unwrap();
    let destination = std::env::args().nth(2).unwrap();
    let socks = tokio_socks::tcp::Socks5Stream::connect(proxy, &destination[..])
        .into_future()
        .map(|_| ())
        .map_err(|_| ());
    tokio::run(socks);
}

Unfortunately it is not possible that way. I even tried to play with lifetimes and realised that tokio-socks requires (it is only hypothesis, I am not very experienced in lifetimes) static lifetime for addresses:

use futures::future::{Future, IntoFuture};
use std::{
    error::Error,
    io::{Error as IoError, ErrorKind},
    net::SocketAddr,
};

type ConnectFuture = Box<dyn Future<Item = tokio::net::TcpStream, Error = IoError> + Send>;

fn connect<'a>(address: &'a String) -> Result<ConnectFuture, Box<dyn Error>> {
    let parts: Vec<_> = address.split("#").collect();
    let (proxy, destination) = (parts[0], parts[1]);
    let proxy = proxy.parse::<SocketAddr>()?;
    Ok(Box::new(
        tokio_socks::tcp::Socks5Stream::connect(proxy, destination)
            .into_future()
            .flatten()
            .map(|tcp| {
                println!("Connected to proxy");
                tcp.into_inner()
            })
            .map_err(|_| IoError::new(ErrorKind::Other, "socks problem")),
    ))
}

fn main() {
    let address = std::env::args().nth(1).unwrap();
    tokio::run(connect(&address).unwrap().map(|_| ()).map_err(|_| ()));
}

rust claims that lifetime of address should be static.

Finally I decided to fork (https://github.com/apatrushev/tokio-socks) and remove all lifetime parameters which fixes the issue. AFAIKS the lifetimes can save only few memory copy which is not so important. Is it possible to fix static requirements? Should I made a PR with lifetimes removal?

Support futures ecosystem (that is: better support for non-tokio runtimes)

Currently the library feels too tightly coupled with tokio. Is it possible to refactor it to allow other runtimes that are compatible with the futures crate (such as smol or async-std)?

Update for Tokio 0.3

Tokio 0.3 is now released.

I have tried to update version here KaranGauswami/tokio-socks in library but looks like This PR tokio-rs/tokio#2919 temporary removed incoming method from tokio::net::TcpListener so currently tests are not compiling in new version.

error[E0599]: no method named `incoming` found for struct `tokio::net::TcpListener` in the current scope
  --> tests/common.rs:26:10
   |
26 |         .incoming()
   |          ^^^^^^^^ method not found in `tokio::net::TcpListener`