In order to be a proper HTTP implementation clients that aren't allowed to connect to the RPC server (using -rpcallowip), should receive a proper HTTP response. So instead of closing the connection on them send a '403 Forbidden' status.
Signed-off-by: Giel van Schijndel me@mortis.eu
I believe this would open up a denial-of-service attack.
The problem is that sending ANY response over an SSL connection starts the SSL handshake. So the attack scenario is:
Attacker connects to your node (and they're not from -rpcallowip address). You're running -ssl=1, so start ssl handshake to return 403 response. Attacker doesn't respond... your rpc process must wait -rpctimeout seconds before proceeding.
Just dropping the connection immediately prevents the attack. Being "a proper HTTP implementation" is not high on the bitcoin wish list.
Right, so what about only sending back a 403 when not using SSL? I'm pretty sure the TCP send window on most OSes these days is enough to fit those few bytes.
As for waiting for the timeout, the network portion of the RPC code could easily enough be rewritten to use asynchronous I/O (by means of Boost.Asio's async_* functions and io_service.(?:poll|run)(?:_one)?).
I was thinking of doing that anyway, as it would allow for easier IPv6 integration (i.e. only at setup time).
In order to be a proper HTTP implementation clients that aren't allowed
to connect to the RPC server (using -rpcallowip), should receive a
proper HTTP response. So instead of closing the connection on them send
a '403 Forbidden' status.
Signed-off-by: Giel van Schijndel <me@mortis.eu>
Signed-off-by: Giel van Schijndel <me@mortis.eu>