Currently it only works on server side. bitcoin-cli needs probably a complete rewrite to work, see more below

Abstract

The goal of this PR is to add full functional SSL support to the Bitcoin Core HTTP Server.

Motivation

At the moment it is not really secure to use Bitcoin Core RPC remotely. (#12763) made it much more secure with restricting access. However the connection level side is still insecure as it works through plain HTTP.

The bitcoin-cli problem

The reason why I am opening this PR in this early state is because it seems like bitcoin-cli will need a rewrite powered by libcurl as libevent has not really good SSL support on the client side (other ideas and help is most welcome). As such a change is major I already wanna ask for r"Concept (N)?ACK" so that such a major change won't be worthless.

OpenSSL again

This PR adds OpenSSL again. I would like if @fanquake could review the first two commits as they mostly consist of reverts from two of his PRs (#17265 and #17165)

Testing

It is already testable. Please be sure to have OpenSSL installed on your system! (Debian: apt install openssl libssl-dev) You should also have cURL installed. The actual testing

1. Generate an SSL cert with openssl req -nodes -new -x509 -keyout server.key -out server.cert. If you have problems with the generation, you can download mine. (DO NOT USE THEM PRODUCTIVELY AS THE PRIVATE KEY IS PUBLICLY AVAILABLE). Download here
2. Compile my branch
3. Start bitcoind with

./bitcoind --server=1 --rpcuser=u --rpcpassword=p --regtest --ssl=1 --sslcert=/home/emil/openssl/server.cert --sslkey=/home/emil/openssl/server.key

(Please adjust the paths according to yours) 4. Do the SSL request (Enter p as password)!

curl --user u -k --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getbestblockhash", "params": [] }' -H 'content-type: text/plain;' https://127.0.0.1:18443/

5. You should see that you just made a successful HTTPS request

Demo (Youtube Video)

@emilengler

Do you see any advantage of handling SSL termination ourselves as opposed to delegating it to say a properly hardened nginx setup? It seems like this would broaden our attack surface and also bring in a highly unwanted dependency :)

For context, Bitcoin Core used to have RPC SSL support. It was hard to use, hardly used, and probably contributed to a false sense of security as the RPC interface is not hardened against untrusted users.

The release notes in 0.12 give a few alternatives: https://bitcoin.org/en/release/v0.12.0#rpc-ssl-support-dropped

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #17730 (depends: remove Qt networking features by fanquake)
• #16895 (External signer multisig support by Sjors)
• #16834 (Fetch Headers over DNS by TheBlueMatt)
• #16762 (Rust-based Backup over-REST block downloader by TheBlueMatt)
• #16549 ([WIP] UI external signer support (e.g. hardware wallet) by Sjors)
• #16546 ([WIP] External signer support - Wallet Box edition by Sjors)
• #15382 (util: add runCommandParseJSON by Sjors)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

#5677 removed SSL for the RPC interface and there are some discussions about the SSL drop in that particular PR. I think adding SSL is a mistake in terms of modularity and security layers. We don't advocate to expose the RPC interface to the public internet and if someone needs a secure connection to the interface, using Wireguard or an Ngnix/Apache reverse proxy with proper certificate based authentication makes much more sense to me. To me it makes little sense if each daemon application has its one httpd/SSL stack. IMO that should be handled by the applications/layers focusing on doing that properly.

The 0.12 release notes also had some examples how to accomplish SSL via a reverse proxy: https://github.com/bitcoin/bitcoin/blob/47d981e8273804a040d71665a4cb16038d6717e1/doc/release-notes/release-notes-0.12.0.md#rpc-ssl-support-dropped

NACK on re-adding OpenSSL dependency. This is not going to happen internally in bitcoind. If you really want this there's various methods to do it (see @jonasschnelli 's post).

To be clear: RPC is meant as a local way of controlling a bitcoind. If it could use a local UNIX socket instead of a TCP port it'd be even better (e.g. #9919 ). If you really want to expose it more widely externally then go ahead and tunnel/sslwrap/nginx/... it, but it shouldn't be encouraged as a built-in option.

Ok, didn’t knew about that SSL existed previously.