Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Protect the Zebra RPC endpoint #8864

Closed
oxarbitrage opened this issue Sep 11, 2024 · 5 comments · Fixed by #8900 or #8940
Closed

Protect the Zebra RPC endpoint #8864

oxarbitrage opened this issue Sep 11, 2024 · 5 comments · Fixed by #8900 or #8940
Assignees
Labels
A-compatibility Area: Compatibility with other nodes or wallets, or standard rules A-rpc Area: Remote Procedure Call interfaces C-security Category: Security issues

Comments

@oxarbitrage
Copy link
Contributor

The Zebra RPC endpoint is currently unencrypted and accessible by anyone who knows the address and port. While the current recommendation is to restrict access to localhost or a trusted local network, there are cases where the endpoint needs to be open to the internet in production environments.

Implement one of the following authentication methods:

  • Basic HTTP Authentication: This method would require users to provide a username and password when connecting to the RPC endpoint.
  • Cookie-based Authentication: Similar to Zcashd, this method uses a randomly generated cookie stored on the file system to authenticate RPC connections.

We could implement just one of these methods or explore alternative solutions.

Authentication should be enabled by default but turning it off should be an option for testing purposes and setups where the endpoint is restricted to localhost or a private network.

Encryption of RPC traffic (for example using TLS) is not part of this ticket but might be considered in the future.

@oxarbitrage oxarbitrage added C-security Category: Security issues A-rpc Area: Remote Procedure Call interfaces A-compatibility Area: Compatibility with other nodes or wallets, or standard rules labels Sep 11, 2024
@mpguerra
Copy link
Contributor

blocking #8830

@conradoplg
Copy link
Collaborator

For reference we discussed this in the past, but any of the proposed approaches look good.

setups where the endpoint is restricted to localhost or a private network.

Note that even in those cases we might need authentication, due to DNS rebinding attacks.

@oxarbitrage
Copy link
Contributor Author

For reference we #4575, but any of the proposed approaches look good.

setups where the endpoint is restricted to localhost or a private network.

Note that even in those cases we might need authentication, due to DNS rebinding attacks.

Thanks for the reference, i knew we had discussed this earlier.

I agree we might need authentication when the endpoint is localhost or private network, so i think Auth should be ON by default but there should be a way to turn it OFF if the user want it.

@gustavovalverde
Copy link
Member

I'd suggest using a JWT token to protect the endpoints by default, and maybe (?) Basic HTTP Authentication as a less-secure alternative (for testing or local environments).

This could be a good read, from the Ethereum JSON-RPC APIs:

And the Rust Ethereum implementation:

@conradoplg
Copy link
Collaborator

I suggest staying away from JWT because it's full of pitfalls. I think doing something similar to zcashd is enough (a random password or token), see https://fly.io/blog/api-tokens-a-tedious-survey/ ("Simply Random Tokens" and JWT sections)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-compatibility Area: Compatibility with other nodes or wallets, or standard rules A-rpc Area: Remote Procedure Call interfaces C-security Category: Security issues
Projects
Status: Done
4 participants