Protect the Zebra RPC endpoint

[oxarbitrage]

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.

[mpguerra]

blocking #8830

[conradoplg]

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]

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]

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:

• https://github.com/ethereum/execution-apis/blob/main/src/engine/authentication.md#key-distribution

And the Rust Ethereum implementation:

• https://reth.rs/docs/reth/rpc/types/engine/struct.JwtSecret.html

[conradoplg]

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)