Zebra: Add Unix socket support to Stolon

Created on 7 Sep 2020  路  11Comments  路  Source: ZcashFoundation/zebra

Is your feature request related to a problem? Please describe.

In the Stolon design RFC (#1006), transactions spread anonymously through the Zcash network using Tor via a SOCKS port.

Tor also supports Unix sockets, which have a number of advantages:

  • Unix sockets are the easiest way to use the iOS Tor.framework: https://github.com/iCepa/Tor.framework#usage
  • Ports can be accessed by any local process, but Unix sockets are protected by filesystem permissions (or are passed between processes as file descriptors)

(Tor.framework can also use host/port connections. But we're not sure if iOS apps can open localhost ports - or if they require extra permissions from the user.)

Describe the solution you'd like

Stolon currently uses tokio-socks::Socks5Stream for its connection to Tor.

  1. Add UnixStream support to tokio-socks::Socks5Stream.

  2. Add a send_transaction_unix_socket method, which takes tor_addr: unix::net::SocketAddr. send_transaction_unix_socket should only be available on Unix platforms - it should require cfg(unix).

See the existing Stolon::send_transaction, which takes a std::net:SocketAddr containing an IPv4 or IPv6 address.

Describe alternatives you've considered

Make the existing send_transaction method generic over std::net::SocketAddr (TCP) and unix::net::SocketAddr (Unix socket). This design might be confusing, because the method would only be generic on Unix platforms. And is much harder to document that the function arguments are conditional on cfg(unix). Rustdoc is designed for conditional functions.

Do nothing. Stolon would be harder to implement on iOS and similar platforms, and less secure on Unix platforms. (Particularly when other network services are running on the same host.)

Additional context

For more context, see the original discussion :
https://github.com/ZcashFoundation/zebra/pull/1006#discussion_r483348582

See also Tor's SOCKS port and unix socket documentation:
https://2019.www.torproject.org/docs/tor-manual.html.en#SocksPort

And Tor.framework's Unix Socket and Port initialisers:
https://github.com/iCepa/Tor.framework/blob/master/Tor/TORController.h#L28

A-rust C-design C-enhancement

All 11 comments

If I understand correctly, the benefits of this change are that on existing platforms (Unix), we'd get better security, and it would allow us to more easily support a new platform (iOS).

In the Unix case, I'm a little unclear on how much of a security improvement we'd get by allowing file permissions for the SOCKS port. What kind of risks are there to sharing the SOCKS listener with other applications on the same system? For something like the Tor control port, it seems much more obvious, but I'm not sure about the SOCKS listener.

If the security benefit on existing platforms (Unix) is relatively marginal, it seems like this would be a good feature to have but probably a low priority until we know we want to support new platforms (iOS) where it's required. Does that seem like a fair assessment?

Another potential complication is that the existing networking code assumes that peer connections are made over TCP, not over Unix sockets. So to support this change, in addition to adding support to the tokio-socks library and changing the stolon API, I think we'd also need to change an unknown amount of the existing network code to allow UnixStreams.

Probably the way to do this would be to make the existing network code generic over an AsyncRead + AsyncWrite implementation, which could have some other benefits. But scoping those changes out might not make sense until we know we want to move forward on implementing this.

This isn't a high priority for us right now - and it's a lot of work.

There is a security benefit - we prevent local processes from exfiltrating data over the SOCKSPort.

@teor2345 how does this relate to Android? Is there an Android equivalent to the iOS Tor.framework? Does it similarly rely on Unix Sockets?

Context:
I'm trying to assess the feasibility of using Stolon and/or Tor on mobile, particularly in conjunction with gRPC. It seems like direct use of Tor from a mobile application is still not quite viable.

@gmale using Tor on iOS and Android is a bit different to the desktop, but it works fine.

Here are some example Tor mobile apps:

Tor Browser for Android originally used Orbot, but they now have their own Tor integration:
https://blog.torproject.org/new-alpha-release-tor-browser-android

I am not sure about the Unix socket requirement for iOS. Tor.framework has a host/port method:
https://github.com/iCepa/Tor.framework/blob/master/Tor/TORController.h#L28

But I don't know if iOS apps can open localhost ports - or if that requires extra permissions. I'll edit the ticket to clarify.

Thanks @teor2345 for pointing me to those useful links. I pulled down the source for orbot and there's a lot there. Ideally, a wallet wouldn't have to rely on the existence of another app on the device and I assume that's at least part of the reason why Tor Browser switched approaches. So I dug around all the Tor open source projects and found a Tor service that seems promising but still feels maybe a bit too bulky for most apps.

I wonder if there is anything out there that streamlines this or takes a more modern approach on Android. I'm not sure what it would take to get gRPC to use Tor as a transport layer. No matter how we approach it, I think network privacy is going to be a very heavy lift on mobile.

@gmale have a chat to The Guardian Project about Tor mobile integration.
Maybe @n8fr8 can point you to the right person or channel?

They are the experts here. I mainly worked on the generic Tor binary/library, rather than integrating it in specific environments.

(Tor can act as a SOCKS or HTTP proxy, so if your gRPC library supports proxy settings, it should be pretty easy to set up.)

Tor Onion Proxy Library is an option:
https://github.com/thaliproject/Tor_Onion_Proxy_Library

Otherwise, there is also our Tor-Android library, which is the Tor binary and some very simple code to configure and start it up:
https://github.com/guardianproject/tor-android

Lastly, you can ask the user to just install Orbot, and if it is available, proxy through the Tor socks/http ports it provides using our NetCipher library:
https://github.com/guardianproject/netcipher

Thanks @n8fr8! There seem to be a lot of options for Android. What would be the best options for iOS, particularly if we want to avoid requiring the user to configure a companion app? Is iCepa the best analog to tor-android?

You'd want to integrate directly with Tor.framework: https://github.com/iCepa/Tor.framework

iCepa is our attempt to move this to an iOS Network Extension approach, but Tor isn't quite ready/able to run in that manner yet.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

teor2345 picture teor2345  路  5Comments

teor2345 picture teor2345  路  3Comments

dconnolly picture dconnolly  路  3Comments

hdevalence picture hdevalence  路  5Comments

teor2345 picture teor2345  路  3Comments