Allow connecting to Zebrad on any hostname

[emersonian]

This patch allows for Zaino to connect to a Zebrad that is not running on localhost.

This is my first-ever Rust pull request so bear with me! I am unsure how to run the tests, am happy to fix anything that broke.

Thank you for your great work on Zaino!

[daira]

I am opposed to merging this. We need to establish a strong security norm and expectation that the connection between Zaino and Zebrad is within a trust boundary. That is, we must be able to make the design assumption that Zaino can trust the Zebrad it is connected to, because it necessarily is run by the same party.

[emersonian]

How can this be tested in a staging environment without the ability to connect to other hosts? I'm all for including warnings in the documentation with your concerns, but restricting to only allowing zebra to run on localhost is excessive and slows down integration testing across stakeholders.

Use case: Zec.rocks has around ten zebra instances synced and running around the world. I took two out of our public load balancers (one mainnet, one testnet) and am pointing Zaino at them for integration testing, all communicating within their clusters' internal networks. There is no security risk in this case, internal communications are encrypted by the Container Network Interface (CNI).

Restricting to localhost slows down the development of Docker Compose and Kubernetes configs for Zaino. Sure, add warnings, but don't force everyone to run Zebra on localhost.

[idky137]

Could we query Zebra's enable_cookie_auth setting using the RPC server? We could then enforce cookie_auth=true when connecting to Zebra remotely? We could also add something similar for Zcashd using the user and password fields in its RPC server. Im not sure how disruptive this would be Zec.rocks though?

[idky137]

Code looks good though!

[idky137]

Hey sorry I haven't got back regarding this.

I want to make sure everyone is happy with the decision we make regarding how we open up Zaino for remote use before merging anything into dev.

We do have work planned for connecting to zebra remotely in Milestone 3 of our current grant (#58) but that is a few months away and will not be focusing on the RPC backend in Zaino.

I want to make sure Zaino can be used how the community wants though so think it would be good to work out a solution for the RPC backend separate to that.

[emersonian]

I suggest that we start by matching the security modeling of lightwalletd rather than further restricting it. Lightwalletd allows connection to node RPCs running on any configurable host, today. If we want to improve upon that level of security, let's decide in a separate discussion.

Zaino must work in containers/Docker. Listening only on localhost blocks supporting containers (reasonably).

[idky137]

I will raise this at one of the next arborist calls, originally I had planned to open up zaino for remote use around this time and agree we are not adding any new security weaknesses but want to check..

We do have time put aside in milestone 3 for enabling "safe" remote access to zebra but I would like to make it possible for you to start testing zaino before then.

Maybe we can merge this functionality under an "unstable" feature flag during development.

EDIT: We are also close to upgrading the JsonRPC backend (#149 is the first of a few PR that will do this) which should give some decent speedups and would be good to start wider testing once this is in..

[zancas]

I have heard a proposal to enable "testing_very_insecure" as a conditionally compiled feature. That seems sensible to me.

I don't think a few months of testing until MileStone 3 is complete is too much time in test mode.

Indeed multiple months in test-mode is almost certainly correct, regardless.

[idky137]

If we are happy with this I will have another look at this pr once #153 lands, there have been some structural changes and I think there will be a couple other places that this code will need to propaget to. I will also look at adding the feature flag.