User's IP address, location should be hidden from lightwalletd using Tor (SOCKS proxy support)

[holmesworcester]

Right now, a lightwalletd server and its hosting provider (e.g. Amazon) knows the user's IP address and approximate physical location.

Since Zcash is a tool focused on providing privacy, its users might prefer that their IP address and physical location are not known to the lightwalletd server and, e.g., Amazon.

To achieve this, I think the following are sufficient:

1. support setting a SOCKS proxy.
2. ensure that zecwallet-light-cli is not leaking any information via DNS, user IP address, etc when it connects via this proxy.

This guide provides more details and warnings: https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO#GeneralTorifyingInformation

Note that this ticket does not encompass all the changes necessary to prevent the lightwalletd server from profiling a user and linking different incoming or outgoing transactions. All it covers is being able to connect via Tor. I'm creating separate tickets for sending transactions and fetching memos.

[holmesworcester]

Created #58 to address privacy / linkability when sending transactions by using Stolon and #59 to address privacy when receiving transactions and fetching blocks for memos.

[gmale]

On a related note, one of the issues here will be gRPC compatibility with SOCKS proxies. I opened an issue, phrased as a user story on the gRPC project because the topic had been quiet for a few years. They recommended using HTTPTunnelPort and indicated that if this is not sufficient we can re-open the issue.

So that may be a good place to start.

[gmale]

Do you envision this being fully solvable on the client side? Would it make sense to open an equivalent issue on the lightwalletd side?

[holmesworcester]

I think there's some additional level of protection by setting up a Tor hidden service for lightwalletd side as well, but basic protection is "solvable" on just the client side, yes.

[holmesworcester]

On a related note, one of the issues here will be gRPC compatibility with SOCKS proxies. I opened an issue, phrased as a user story on the gRPC project because the topic had been quiet for a few years. They recommended using HTTPTunnelPort and indicated that if this is not sufficient we can re-open the issue.

So that may be a good place to start.

Ohh, that would be helpful, yes. Then we would just have to change the URL of the lightwalletd and point to a port on localhost.

[adityapk00]

I think connecting over TOR is feasible. We can proceed in steps:

1. Have zecwallet-light-cli support connecting over plain HTTP, so that it can use a grpc-proxy like envoy to connect over the proper internet
2. Add SOCKS proxy/TOR support to zecwallet-light-cli, so that the connections can go over TOR instead of over the internet
3. Modify lightwalletd to expose the service as a TOR hidden service, which zecwallet-light-cli can then directly connect to, achieving full network privacy.

[adityapk00]

As a side note - HTTPTunnerPort is probably not a good path to go down, since it will require that the user using the wallet change some TOR settings, making it harder to use. If we go down the envoy / grpc-proxy route, all the user has to do is install TOR, and zecwallet-light-cli will automatically be able to use it without any config changes.

[holmesworcester]

that sounds awesome.

…

On Oct 16, 2020, at 1:24 PM, adityapk00 ***@***.***> wrote: As a side note - HTTPTunnerPort is probably not a good path to go down, since it will require that the user using the wallet change some TOR settings, making it harder to use. If we go down the envoy / grpc-proxy route, all the user has to do is install TOR, and zecwallet-light-cli will automatically be able to use it without any config changes. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#57 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABUFLU2LBW4TQYPWEI5A3TSLB6WVANCNFSM4SAYUCUQ>.

[holmesworcester]

Also, what about #58 for sending via Stolon? Does that seem doable?

[gmale]

over plain HTTP, so that it can use . . . envoy to connect over the proper internet

can you explain this in a little more detail? Do we need to drop TLS to use envoy? On the Android side, it seems like we might be able to use netcipher to keep TLS.

all the user has to do is install TOR

I really don't like the idea requiring a TOR companion app installation on mobile. On the android side, it looks like we can get TOR to work without requiring additional installation via the tor-android library. iCepa might be an option on iOS side. There is a quality discussion on this topic here.

[adityapk00]

Sorry, when I mean HTTP, I meant HTTPS. The connection will use TLS, and will be encrypted by default.

I meant we'll use the HTTP/1.1 protocol, with TLS to connect (rather than gRPC, which uses HTTP/2.0, which TOR doesn't have good support for).

On the lightwalletd server, envoy acts as a reverse proxy, converting the HTTPS requests to gRPC, so that the client can talk over HTTPS instead of gRPC.

The advantage of this is that we won't need any extra config on the TOR side of things. All the user has to do is install TOR, on desktop/mobile, and Zecwallet will use that connection, and connect over HTTPS

Zecwallet --HTTPS (over HTTP/1.1)---> envoy-proxy ---(gRPC HTTP/2.0)---> lightwalletd

Envoy proxy and lightwalletd are deployed on the same server in the cloud, making infra management easier

[gmale]

Makes sense. This sounds similar to what javascript does with grpc-web to make grpc work w/o using HTTP/2. Is this what you're already doing on lightd-main.zecwallet.co? Is that why it uses port 443?

Ideally, it would be nice if we could:

1. Enable Tor support and allow it to be optional
   • Reason: optional because some want it while others feel that Tor exit nodes invite additional risks and rather not use it
2. Not require a separate Tor installation or companion app
   • Reason: the apps should be self-contained and easy to use (w/o additional instructions/config)
3. Keep gRPC at the network and application layers
   • Reason: redoing the network stack is a lot of work. gRPC is binary, fast and efficient and uses protobufs well (which provide lots of benefits like a clear and documented schema for models and services). Mobile is trending in this direction and general gRPC (and HTTP/2) adoption is growing.
4. Keep TLS
   • Reason: HTTP should be out of the question because it's so easy to intercept. HTTPS (with TLS as a sublayer) is the only way to go.
5. Not require extra configuration on the TOR side of things
   • Reason: same as number 2

It seems like we can achieve all these things, across all platforms, with a combination of: Envoy, tor-android, iCepa's Tor.Framework, and (maybe) HTTPTunnelPort

[holmesworcester]

Reason: optional because some want it while others feel that Tor exit nodes invite additional risks and rather not use it

FWIW, the attacks described in this article shouldn't affect the zecwallet-lite-cli / lightwalletd connection, which uses SSL. Running a lightwalletd server as an onion service would cut out malicious exit nodes entirely, I think.