Enabling SSL on original client daemon: Difference between revisions
Jump to navigation
Jump to search
Frankenmint (talk | contribs) fill in more contextual details rather than a 1 liner |
Frankenmint (talk | contribs) No edit summary |
||
| Line 1: | Line 1: | ||
JSON-RPC over SSL is strongly discouraged | 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 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." | "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." | ||
-[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)] | ||
Revision as of 22:44, 22 March 2016
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 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."