Enabling SSL on original client daemon: Difference between revisions
Frankenmint (talk | contribs) No edit summary |
m spelling, grammar |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
"The RPC interface isn't designed to be used in any scenario which would require SSL, which would be | SSL for RPC in Bitcoin Core client, was '''removed and is no longer available''' (as of 2019.03) apparently in commit 40b556d374 . | ||
Even before its removal, it was criticized for some time. | |||
=== Historical comments === | |||
(this no longer applies as RPC SSL was removed). | |||
JSON-RPC over [https://en.wikipedia.org/wiki/Secure_Sockets_Layer SSL] is strongly discouraged | |||
"The RPC interface isn't designed to be used in any scenario which would require SSL, which would be accessed 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." | |||
-[https://bitcoin.stackexchange.com/questions/39117/why-is-json-rpc-over-ssl-strongly-discouraged Bitcoin(StackExchange, August 17th, 2015)] | -[https://bitcoin.stackexchange.com/questions/39117/why-is-json-rpc-over-ssl-strongly-discouraged Bitcoin(StackExchange, August 17th, 2015)] | ||
Latest revision as of 07:51, 26 September 2022
SSL for RPC in Bitcoin Core client, was removed and is no longer available (as of 2019.03) apparently in commit 40b556d374 .
Even before its removal, it was criticized for some time.
Historical comments
(this no longer applies as RPC SSL was removed).
JSON-RPC over SSL is strongly discouraged
"The RPC interface isn't designed to be used in any scenario which would require SSL, which would be accessed 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."