7 ms·

No, Bitcoin doesn't use SSL/TLS. It could have implications for Bitcoin web services that use HTTPS, of course.

gojomo 13y ago
Yes, Bitcoin the system/protocol doesn't inherently use TLS. But, with the "rpcssl=1" option, the reference Bitcoin client's RPC interface would be using SSL, and specifically OpenSSL. I'd guess a ton of online Bitcoin services reliant on hot wallets do this. So cue the thefts, or 'thefts', any minute now.
- tlrobinson 13y ago
  True, though I would hope most services don't have public facing bitcoind instances to begin with...
  - gojomo 13y ago
    Ideally, no, but with SSL, and a very-strong password, it might not be worse than other options for automating payouts... until a major bug like this comes along. For comparison, the Bitcoin RPC password timing bug - https://github.com/bitcoin/bitcoin/issues/2838 https://github.com/bitcoin/bitcoin/issues/2838 - would have been a more slower and blatant/detectable way to compromise the same sorts of bitcoin RPC daemons.
- nwh 13y ago
  Nobody exposes their RPC port over ssl publicly. Nobody. You can't even do it if you use the normal settings in the client.
  - gojomo 13y ago
    I'm fairly confident that you're wrong about "nobody"... but you'll have to find the examples yourself. Yes, it requires extra settings in bitcoin.conf: to enable RPC, accept connections from non-local addresses, and use SSL. But it's only 5 lines if the host is not otherwise firewalled from the net: server=1 rpcuser=reckless rpcpassword=passw0rd rpcallowip=* rpcssl=1 (Actually, I'm not sure if rpcuser and rpcpassword absolutely must be set...)
M4v3R 13y ago
But couldn't it be the case that with this bug you could sweep private keys from server's memory if they happen to be in there, because bitcoind is using them at the moment?
- tlrobinson 13y ago
  Yes, I would put that under the "implications for Bitcoin web services that use HTTPS" category. For context, the deleted question asked about the "Bitcoin blockchain" so I was responding to that specifically, with the added caveat for Bitcoin services that use HTTPS.

Yes, Bitcoin the system/protocol doesn't inherently use TLS. But, with the "rpcssl=1" option, the reference Bitcoin client's RPC interface would be using SSL, and specifically OpenSSL. I'd guess a ton of online Bitcoin services reliant on hot wallets do this. So cue the thefts, or 'thefts', any minute now.

tlrobinson 13y ago
True, though I would hope most services don't have public facing bitcoind instances to begin with...
- gojomo 13y ago
  Ideally, no, but with SSL, and a very-strong password, it might not be worse than other options for automating payouts... until a major bug like this comes along. For comparison, the Bitcoin RPC password timing bug - https://github.com/bitcoin/bitcoin/issues/2838 https://github.com/bitcoin/bitcoin/issues/2838 - would have been a more slower and blatant/detectable way to compromise the same sorts of bitcoin RPC daemons.
nwh 13y ago
Nobody exposes their RPC port over ssl publicly. Nobody. You can't even do it if you use the normal settings in the client.
- gojomo 13y ago
  I'm fairly confident that you're wrong about "nobody"... but you'll have to find the examples yourself. Yes, it requires extra settings in bitcoin.conf: to enable RPC, accept connections from non-local addresses, and use SSL. But it's only 5 lines if the host is not otherwise firewalled from the net: server=1 rpcuser=reckless rpcpassword=passw0rd rpcallowip=* rpcssl=1 (Actually, I'm not sure if rpcuser and rpcpassword absolutely must be set...)

M4v3R 13y ago

But couldn't it be the case that with this bug you could sweep private keys from server's memory if they happen to be in there, because bitcoind is using them at the moment?

tlrobinson 13y ago
Yes, I would put that under the "implications for Bitcoin web services that use HTTPS" category. For context, the deleted question asked about the "Bitcoin blockchain" so I was responding to that specifically, with the added caveat for Bitcoin services that use HTTPS.