Enabling SSL on original client daemon - Revision history

AllEd01: spelling, grammar

2022-09-26T07:51:49Z

spelling, grammar

← Older revision		Revision as of 07:51, 26 September 2022
Line 2:		Line 2:
	SSL for RPC in Bitcoin Core client, was '''removed and is no longer available''' (as of 2019.03) apparently in commit 40b556d374 .		SSL for RPC in Bitcoin Core client, was '''removed and is no longer available''' (as of 2019.03) apparently in commit 40b556d374 .

	Even before removal, it was for some time ~~being criticised~~.		Even before its removal, it was criticized for some time.

	=== Historical comments ===		=== Historical comments ===
Line 10:		Line 10:
	JSON-RPC over [https://en.wikipedia.org/wiki/Secure_Sockets_Layer SSL] is strongly discouraged		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 ~~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 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)]

Rafalcpp: style fix

2019-03-08T12:24:15Z

style fix

← Older revision		Revision as of 12:24, 8 March 2019
Line 4:		Line 4:
	Even before removal, it was for some time being criticised.		Even before removal, it was for some time being criticised.

	## Historical comments:		=== 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		JSON-RPC over [https://en.wikipedia.org/wiki/Secure_Sockets_Layer SSL] is strongly discouraged

Rafalcpp: rpc ssl was removed

2019-03-08T12:23:35Z

rpc ssl was removed

← Older revision		Revision as of 12:23, 8 March 2019
Line 1:		Line 1:

			SSL for RPC in Bitcoin Core client, was '''removed and is no longer available''' (as of 2019.03) apparently in commit 40b556d374 .

			Even before removal, it was for some time being criticised.

			## Historical comments:


	JSON-RPC over [https://en.wikipedia.org/wiki/Secure_Sockets_Layer SSL] is strongly discouraged		JSON-RPC over [https://en.wikipedia.org/wiki/Secure_Sockets_Layer SSL] is strongly discouraged

Frankenmint at 22:45, 22 March 2016

2016-03-22T22:45:34Z

← Older revision		Revision as of 22:45, 22 March 2016
Line 1:		Line 1:
	JSON-RPC over [[SSL]] is strongly discouraged		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 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)]

Frankenmint at 22:44, 22 March 2016

2016-03-22T22:44:18Z

← Older revision		Revision as of 22:44, 22 March 2016
Line 1:		Line 1:
	JSON-RPC over SSL is strongly discouraged~~[[1]]~~		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)]

Frankenmint: fill in more contextual details rather than a 1 liner

2016-03-22T22:43:52Z

fill in more contextual details rather than a 1 liner

← Older revision		Revision as of 22:43, 22 March 2016
Line 1:		Line 1:
	JSON-RPC over SSL is strongly discouraged		JSON-RPC over SSL is strongly discouraged[[1]]

			"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)]

Phantomcircuit: Replaced content with "JSON-RPC over SSL is strongly discouraged"

2015-04-23T02:19:57Z

Replaced content with "JSON-RPC over SSL is strongly discouraged"

← Older revision		Revision as of 02:19, 23 April 2015
Line 1:		Line 1:
	== JSON-RPC ~~Over~~ SSL ~~Setup ==~~		JSON-RPC over SSL is strongly discouraged

	~~By default, bitcoin allows JSON-RPC commands to be sent to~~
	~~http://localhost:8332/, and accepts connections only from the local~~
	~~host.~~

	~~It can be configured to allow https connections from other hosts;~~
	~~three things must be setup for this to work properly:~~

	~~1. You must setup a server certificate and private key. A self-signed~~
	~~certificate will work nicely, you don't need to pay for a certificate signed by~~
	~~a certificate authority.~~

	~~By default, bitcoin looks for the server's private key file in a~~
	~~"server.pem" in the bitcoin data directory (e.g. ~/.bitcoin/server.pem~~
	~~on unix), and the server certificate file in "server.cert". To~~
	~~generate them using the openssl command-line program, run:~~

	~~cd ~/.bitcoin~~
	~~openssl genrsa -out server.pem 2048~~
	~~openssl req -new -x509 -nodes -sha1 -days 3650 -key server.pem > server.cert~~

	~~You should NOT enter a passphrase.~~

	~~2. Specify the IP addresses of clients that are allowed to connect using~~
	~~"rpcallowip" configuration file options.~~

	~~Edit the bitcoin.conf file (in the bitcoin data directory), and add a~~
	~~line for each IP address allowed to connect:~~
	~~rpcallowip=10.11.13.15~~
	~~rpcallowip=10.11.13.16~~
	~~You may also allow connections from any IP address in a subnet using *:~~
	rpcallowip=192.168.1.*
	rpcallowip=10.1..
	~~You can also specify 'rpcallowip=*' to allow all IP addresses.~~

	~~Connections from the local host (127.0.0.1) are always allowed.~~

	~~3. You must tell bitcoin to use ssl using the "rpcssl" configuration file option.~~

	~~Edit the bitcoin.conf file, and add:~~
	~~rpcssl=1~~

	~~Restart bitcoin or bitcoind to make these changes take effect. You~~
	~~can test bitcoin's ssl functionality using the openssl s_client command:~~

	~~openssl s_client -connect localhost:8332~~

	~~The connection should be successful and you should see the server's~~
	~~certificate details. If you press return twice, you should get a~~
	~~'HTTP/1.0 401 Authorization Required' response.~~

	~~[[Category:Technical]]~~
	~~[[Category:Developer]]~~

	~~== Client setup ==~~

	~~Once the server is accepting https connections, to be secure you should~~
	~~make sure the client is actually connecting to the bitcoin server and~~
	~~not an attacker trying to hijack the connection.~~

	~~If you can, you should copy the server.cert certificate chain file to~~
	~~the client machine and use it to validate the OpenSSL connection.~~
	~~For example, in php you would call stream_context_create() with~~
	~~the 'verify_peer' and 'ca_file' options and then call~~
	~~stream_context_set_default().~~

	~~If you can't validate using the server certificate, you should connect~~
	~~to the server using its IP address instead of its host name.~~

	~~== bitcoin.conf Options ==~~

	~~All HTTPS-JSON-RPC-related bitcoin.conf options:~~

	~~{\| class="wikitable"~~
	\|-
	~~! Option !! Default !! Description~~
	\|-
	~~\| rpcport \|\|8332\|\|Listen for connections on this port~~
	\|-
	~~\| rpcuser \|\| -none- \|\|user name for HTTP BASIC authentication~~
	\|-
	~~\| rpcpassword \|\| -none- \|\|password for HTTP BASIC authentication~~
	\|-
	~~\| rpcssl \|\| -none- \|\| Not set by default, if set bitcoin will only accept SSL connections~~
	\|-
	~~\| rpcallowip \|\| -none- \|\| Allow a client at this IP address to connect (may be specified multiple times)~~
	\|-
	~~\| rpcsslciphers \|\| TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!AH:!3DES:@STRENGTH \|\| See the openSSL documentation for syntax~~
	\|-
	~~\| rpcsslcertificatechainfile \|\| server.cert \|\| File containing server's public key~~
	\|-
	~~\|\| rpcsslprivatekeyfile \|\| server.pem \|\| File containing server's private key~~
	\|}

	~~== Known Problems ==~~

	As of April 2011, Google's App Engine urlfetch service only supports the following ciphers: RC4-MD5, RC4-SHA, DES-CBC3-SHA None of those are secure enough to match the default rpcsslciphers list. The workaround is ~~to specify:~~
	~~rpcsslciphers=DEFAULT:@STRENGTH~~
	~~in the bitcoin.conf file.~~

Gavinandresen: Added to Technical and Developer categories

2012-11-28T19:42:53Z

Added to Technical and Developer categories

← Older revision		Revision as of 19:42, 28 November 2012
Line 50:		Line 50:
	certificate details. If you press return twice, you should get a		certificate details. If you press return twice, you should get a
	'HTTP/1.0 401 Authorization Required' response.		'HTTP/1.0 401 Authorization Required' response.

			[[Category:Technical]]
			[[Category:Developer]]

	== Client setup ==		== Client setup ==

Gavinandresen: /* Known Problems */

2011-04-22T17:34:42Z

Known Problems

← Older revision		Revision as of 17:34, 22 April 2011
Line 93:		Line 93:
	== Known Problems ==		== Known Problems ==

	As of ~~October 2010~~, Google's App Engine urlfetch service only supports the following ciphers: RC4-MD5, RC4-SHA, DES-CBC3-SHA None of those are secure enough to match the default rpcsslciphers list. The workaround is to specify:		As of April 2011, Google's App Engine urlfetch service only supports the following ciphers: RC4-MD5, RC4-SHA, DES-CBC3-SHA None of those are secure enough to match the default rpcsslciphers list. The workaround is to specify:
	rpcsslciphers=DEFAULT:@STRENGTH		rpcsslciphers=DEFAULT:@STRENGTH
	in the bitcoin.conf file.		in the bitcoin.conf file.

Gavinandresen: /* Known Problems */

2011-04-22T17:34:27Z

Known Problems

← Older revision		Revision as of 17:34, 22 April 2011
Line 91:		Line 91:
	\|}		\|}

	~~====~~== Known Problems ~~====~~==		== Known Problems ==

	As of October 2010, Google's App Engine urlfetch service only supports the following ciphers: RC4-MD5, RC4-SHA, DES-CBC3-SHA None of those are secure enough to match the default rpcsslciphers list. The workaround is to specify:		As of October 2010, Google's App Engine urlfetch service only supports the following ciphers: RC4-MD5, RC4-SHA, DES-CBC3-SHA None of those are secure enough to match the default rpcsslciphers list. The workaround is to specify:
	rpcsslciphers=DEFAULT:@STRENGTH		rpcsslciphers=DEFAULT:@STRENGTH
	in the bitcoin.conf file.		in the bitcoin.conf file.