feat(rpc): Cookie auth system for the RPC endpoint

[oxarbitrage]

Motivation

We want to authenticate the RPC method by the zcashd cookie method.

Close #8864

Solution

• Added enable_cookie_auth config field to use cookie authentication, enabled by default.
• Generate cookie when the RPC endpoint starts.
• Start the RPC endpoint server with that generated cookie.
• In the middleware, if auth is enabled, check for basic HTTP auth header.
  • Redirect to request if the user provided auth matches the one generated that the server has.
  • Else error 401.

Tests

• Manual
• All tests should remain working as we disabled auth for all of them.

Follow-up Work

• Make the python RPC tests work with authproxy again, or/and:
  • Create a rust test to query with auth.

PR Author's Checklist

• The PR name will make sense to users.
• The PR provides a CHANGELOG summary.
• The solution is tested.
• The documentation is up to date.
• The PR has a priority label.

PR Reviewer's Checklist

• The PR Author's checklist is complete.
• The PR resolves the issue.

[oxarbitrage]

Requests from a remote host that don't have the cookie generated at startup will be rejected. In zcashd, the zcash-cli can be used in a remote host that has the cookie and authenticate. However, we are not targeting a specific application, we want to use the authentication method in a generic way from a remote client. One option can be to use curl with the cookie file and compare server side. Other options are welcome, i am still brainstorming it.

[oxarbitrage]

We had a chat today about this with @upbqdn and @arya2, i am adding some more research here.

About the cookie auth method:

... Read access to this file controls who can access through RPC ...

https://bitcoin.org/en/release/v0.12.0#rpc-random-cookie-rpc-authentication

That means the cookie method is actually for local access. I think we should focus on that in this PR.

For remote access, we thought in username/password over TLS/SSL as an option. Bitcoin supported this for its RPC endpoint in the past however they don't do it anymore claiming that the RPC access should only be shared with trusted environments.

https://en.bitcoin.it/wiki/Enabling_SSL_on_original_client_daemon#:~:text=SSL%20for%20RPC%20in%20Bitcoin,was%20criticized%20for%20some%20time.

https://bitcoin.stackexchange.com/questions/108293/why-does-bitcoin-cores-rpc-interface-not-use-encryption

It seems that the remote access should be a combination of username and password, with the additional rpcallowip config option plus a vpn layer.

[oxarbitrage]

Continuing with the cookie auth method, the zcash-cli sends the cookie content as basic HTTP credentials to the server: https://github.com/zcash/zcash/blob/master/src/bitcoin-cli.cpp#L251
https://github.com/zcash/zcash/blob/master/src/bitcoin-cli.cpp#L266

We want to do that but just with curl, we need to intercept the Authorization in the zebra RPC middleware and compare it with the cookie in the server side.

I got confused thinking the cookie method will work for remote access, my apologies for that.

[upbqdn]

That means the cookie method is actually for local access. I think we should focus on that in this PR.

Do we have any use cases that require authentication for local access, though?

[oxarbitrage]

Do we have any use cases that require authentication for local access, though?

It's a security measure. You can't access the resources if you don't have read access to the cookie, even if you are in the same machine.

[mpguerra]

Can this be merged once approved?

[upbqdn]

Can this be merged once approved?

Nope.

[upbqdn]

This PR is missing a priority label.

[upbqdn]

Should we also update user docs and describe where users can find the cookie and how to use it?