<p>The RPC interface isn't designed to be used in any scenario which would require SSL, which would be access over the internet or other untrusted networks. It doesn't have the necessary denial of service protections or review to make it safe for use this way, and so letting potentially malicious clients connect to it would be incredibly unwise. If you need to talk to a remote <code>bitcoind</code> instance you are better off tunneling with <code>SSH</code> or <code>stunnel</code> which will provide a secure, authenticated path without exposing the socket any further than localhost. </p>

<p>As of 2017, support for RPC SSL has been completely removed to support the continued move away from reliance on OpenSSL in the daemon (unfortunately BIP70 mandates its inclusion for the GUI client). </p>

<p>As of 2019, all reliance on OpenSSL has been successfully removed from <code>bitcoind</code>. </p>

CC BY-SA 3.0
2016-03-22T22:41:13.520Z
can I add this to the bitcoin wiki??? ermmm Screw it I'm doing it!
Frankenmint
CC BY-SA 3.0
2017-04-07T15:06:50.713Z
the year is now 2017, and it seems RPC SSL support has been dropped altogether. Instead, the release notes recommend using OS specific tunneling mechanisms. Cheers. https://bitcoin.org/en/release/v0.12.0#rpc-ssl-support-dropped
Jesús Zazueta
CC BY-SA 3.0
2017-05-04T12:55:28.140Z
Also hence the release notes when SSL was dropped. Mentions some solutions: https://github.com/bitcoin/bitcoin/blob/d6a92dd0ea42ec64f15b81843b4db62c7b186bdb/doc/release-notes.md#ssl-support-for-rpc-dropped
Jonas Schnelli
CC BY-SA 3.0
2017-10-19T16:58:40.457Z
can I use IPSEC ?
Haddar Macdasi
CC BY-SA 4.0
2021-03-24T01:42:27.007Z
i didn't quite understand the reasoning; passing sensitive information in cleartext is a bigger problem, it's a big no-no. (it's listed as a common weakness https://cwe.mitre.org/data/definitions/319.html )
MichaelMoser
CC BY-SA 4.0
2021-03-24T03:16:25.767Z
It's not the responsibility of Bitcoin Core to provide a secure transport. The RPC interface is supposed to be used locally to a system where encryption is not required, if it is to be used remotely, a user can provide their own transport such as wireguard or even SSL if they so choose, but it's not safe for it to be a built in. The prior existence of SSL in Bitcoin Core has directly resulted in memory corruption in OpenSSL leaking secure memory from the client.
Claris
CC BY-SA 4.0
2015-08-17T03:10:03.683Z
2019-04-26T13:04:31.230Z
2019-04-26T13:04:31.230Z
Claris
<p>The Wiki contains <a href="https://en.bitcoin.it/wiki/Enabling_SSL_on_original_client_daemon">a page</a> that simply states:</p>

<blockquote>
  <p>JSON-RPC over SSL is strongly discouraged</p>
</blockquote>

<p>Why?</p>

<p>I found a method for enabling JSON_RPC over SSL <a href="https://bitcoinsecurityproject.org/BTCProtocol/JSONRPC/">here</a>. The post mentions nothing about JSON-RPC over SSL being strongly discouraged. What risks do I run by using it?</p>

CC BY-SA 4.0
2021-02-23T11:12:01.777Z
Note to other readers: This question is about the use of a command interface for Bitcoin software, and does not really have anything to do wtih JSON-RPC.
Zero3
<security><json-rpc><ssl>
Why is JSON-RPC over SSL "strongly discouraged"?
Rich Apodaca
# Why is JSON-RPC over SSL "strongly discouraged"?

(Asked by: username_0 on 2015-08-17)

The Wiki contains [a page](https://en.bitcoin.it/wiki/Enabling_SSL_on_original_client_daemon) that simply states:

> JSON-RPC over SSL is strongly discouraged

Why?

I found a method for enabling JSON\_RPC over SSL [here](https://bitcoinsecurityproject.org/BTCProtocol/JSONRPC/). The post mentions nothing about JSON-RPC over SSL being strongly discouraged. What risks do I run by using it?

**Tags:** security, json-rpc, ssl

> **Comments:**
> **username_1**: Note to other readers: This question is about the use of a command interface for Bitcoin software, and does not really have anything to do wtih JSON-RPC.  

---

## 1 answers

### Answer by username_2 on 2015-08-17. Score: 11

The RPC interface isn't designed to be used in any scenario which would require SSL, which would be access over the internet or other untrusted networks. It doesn't have the necessary denial of service protections or review to make it safe for use this way, and so letting potentially malicious clients connect to it would be incredibly unwise. If you need to talk to a remote `bitcoind` instance you are better off tunneling with `SSH` or `stunnel` which will provide a secure, authenticated path without exposing the socket any further than localhost.

As of 2017, support for RPC SSL has been completely removed to support the continued move away from reliance on OpenSSL in the daemon (unfortunately BIP70 mandates its inclusion for the GUI client).

As of 2019, all reliance on OpenSSL has been successfully removed from `bitcoind`.

> **Comments:**
> **username_3**: can I add this to the bitcoin wiki??? ermmm Screw it I'm doing it!  
> **username_4**: the year is now 2017, and it seems RPC SSL support has been dropped altogether. Instead, the release notes recommend using OS specific tunneling mechanisms. Cheers. https://bitcoin.org/en/release/v0.12.0#rpc-ssl-support-dropped  
> **username_5**: Also hence the release notes when SSL was dropped. Mentions some solutions: https://github.com/bitcoin/bitcoin/blob/d6a92dd0ea42ec64f15b81843b4db62c7b186bdb/doc/release-notes.md#ssl-support-for-rpc-dropped  
> **username_6**: can I use IPSEC ?  
> **username_7**: i didn't quite understand the reasoning; passing sensitive information in cleartext is a bigger problem, it's a big no-no. (it's listed as a common weakness https://cwe.mitre.org/data/definitions/319.html )  
> **username_2**: It's not the responsibility of Bitcoin Core to provide a secure transport. The RPC interface is supposed to be used locally to a system where encryption is not required, if it is to be used remotely, a user can provide their own transport such as wireguard or even SSL if they so choose, but it's not safe for it to be a built in. The prior existence of SSL in Bitcoin Core has directly resulted in memory corruption in OpenSSL leaking secure memory from the client.  

---

