2021-05-25 20:41:23 +01:00
|
|
|
|
# tor-socksproto
|
|
|
|
|
|
|
|
|
|
|
|
Implements SOCKS in the flavors provided by Tor.
|
|
|
|
|
|
|
|
|
|
|
|
## Overview
|
|
|
|
|
|
|
|
|
|
|
|
SOCKS is an old and somewhat janky protocol for telling a TCP
|
|
|
|
|
|
proxy where to connect. Versions 4, 4a, and 5 are sometimes
|
|
|
|
|
|
encountered in the wild.
|
|
|
|
|
|
|
|
|
|
|
|
The `tor-socksproto` crate tries to hide the actual details of the
|
2022-05-06 14:51:11 +01:00
|
|
|
|
protocol, and expose a stateful handshake type that eventually
|
2021-08-11 18:33:34 +01:00
|
|
|
|
provides a [`SocksRequest`] or an error. It is part of
|
2021-05-25 20:41:23 +01:00
|
|
|
|
[Arti](https://gitlab.torproject.org/tpo/core/arti/), a project to
|
|
|
|
|
|
implement [Tor](https://www.torproject.org/) in Rust.
|
|
|
|
|
|
At present, it is only used to provide a
|
|
|
|
|
|
SOCKS proxy _over_ the Tor network, but eventually it may be used
|
|
|
|
|
|
to implement support for connecting to the Tor network over a
|
|
|
|
|
|
SOCKS proxy.
|
|
|
|
|
|
|
|
|
|
|
|
This crate may be a good choice for you if you need a SOCKS
|
|
|
|
|
|
implementation that "behaves like Tor", but otherwise it is
|
|
|
|
|
|
probably better to use some other SOCKS crate.
|
|
|
|
|
|
|
|
|
|
|
|
For more information about SOCKS:
|
|
|
|
|
|
|
|
|
|
|
|
* SOCKS5 (which is preferred) is specified in
|
|
|
|
|
|
[RFC 1928](https://tools.ietf.org/html/rfc1928), and see also
|
|
|
|
|
|
[RFC 1929](https://tools.ietf.org/html/rfc1929) for
|
|
|
|
|
|
Username/Password authentication in SOCKS5.
|
|
|
|
|
|
* [The wikipedia article](https://en.wikipedia.org/wiki/SOCKS)
|
|
|
|
|
|
is the best surviving documentation for SOCKS4 and SOCKS4a.
|
|
|
|
|
|
* See
|
|
|
|
|
|
[socks-extensions.txt](https://spec.torproject.org/socks-extensions)
|
|
|
|
|
|
for a description of Tor's extensions and restrictions on the
|
|
|
|
|
|
SOCKS protocol.
|
|
|
|
|
|
|
|
|
|
|
|
### Design notes
|
|
|
|
|
|
|
|
|
|
|
|
Arti uses this crate instead of some other SOCKS implementation,
|
|
|
|
|
|
for two reasons:
|
|
|
|
|
|
|
|
|
|
|
|
* First, because we need to support Tor SOCKS extensions.
|
2022-05-06 14:51:11 +01:00
|
|
|
|
* Second, and because we sometimes need to see particular details
|
2021-05-25 20:41:23 +01:00
|
|
|
|
of the individual handshakes that most other SOCKS
|
|
|
|
|
|
implementations don't expose. (For example, if we are told to
|
|
|
|
|
|
connect to a raw IP address, the type of the handshake can help
|
2022-05-06 14:51:11 +01:00
|
|
|
|
us guess whether that IP address came from a DNS response–in
|
2021-05-25 20:41:23 +01:00
|
|
|
|
which case we should warn about a possible DNS leak.)
|
|
|
|
|
|
|
|
|
|
|
|
Currently, `tor-socksproto` does no networking code: it _only_
|
|
|
|
|
|
implements the server (proxy) side of the SOCKS handshake by
|
|
|
|
|
|
handling a series of bytes. We may (or may not) want to add
|
|
|
|
|
|
network functionality to this crate or elsewhere in the future.
|
|
|
|
|
|
We'll definitely want to add client functionality.
|
|
|
|
|
|
|
|
|
|
|
|
Possibly, this approach will prove useful for other uses. If it
|
2022-05-06 14:51:11 +01:00
|
|
|
|
does, We can put the tor-only functionality behind a Cargo build
|
2021-05-25 20:41:23 +01:00
|
|
|
|
feature, so that others can use this crate more safely.
|
|
|
|
|
|
|
|
|
|
|
|
License: MIT OR Apache-2.0
|
