Since the information exchanged between the pool and the miner is
public, all that's needed is a mutual private MAC key that authenticates
messages.
This requires a registration step, that can be done only once using a
simple web interface over https to the miner website.
But the miner website is
On Thu, Aug 07, 2014 at 11:45:44PM +, Luke Dashjr wrote:
On Thursday, August 07, 2014 11:02:21 PM Pedro Worcel wrote:
Hi there,
I was wondering if you guys have come across this article:
http://www.wired.com/2014/08/isp-bitcoin-theft/
The TL;DR is that somebody is abusing the
On Fri, Aug 08, 2014 at 11:42:52AM +0200, Mike Hearn wrote:
AFAIK the only protection is SSL + certificate validation on client side.
However certificate revocation and updates in miners are pain in the ass,
that's why majority of pools (mine including) don't want to play with
that...
Certificate validation isn't needed unless the attacker can do a direct
MITM
at connection time, which is a lot harder to maintain than injecting a
client.reconnect.
Surely the TCP connection will be reset once the route reconfiguration is
completed, either by the MITM server or by the
gmaxwell noted on IRC that enabling TLS could be functionally, if not
literally, a DoS on the pool servers. Hence the thought towards a
more lightweight method that simply prevents client payout redirection
+ server impersonation.
On Fri, Aug 8, 2014 at 5:53 AM, Mike Hearn m...@plan99.net
On Friday, August 08, 2014 6:21:18 PM Jeff Garzik wrote:
gmaxwell noted on IRC that enabling TLS could be functionally, if not
literally, a DoS on the pool servers. Hence the thought towards a
more lightweight method that simply prevents client payout redirection
+ server impersonation.
My
Mutual CHAP could work. This is commonly done in PPP and iSCSI. The idea is
simply that both sides authenticate. The server expects the client to provide
a password, and the client expects the server to provide a (different)
password. If you masquerade as the server, you won't be able to
On Thursday, August 07, 2014 11:02:21 PM Pedro Worcel wrote:
Hi there,
I was wondering if you guys have come across this article:
http://www.wired.com/2014/08/isp-bitcoin-theft/
The TL;DR is that somebody is abusing the BGP protocol to be in a position
where they can intercept the miner
AFAIK the only protection is SSL + certificate validation on client side.
However certificate revocation and updates in miners are pain in the ass,
that's why majority of pools (mine including) don't want to play with
that...
slush
On Fri, Aug 8, 2014 at 1:45 AM, Luke Dashjr l...@dashjr.org
What exactly makes bitcoin less of a target than a scamcoin which I
suspect means anything that != bitcoin?
On 7 August 2014 20:29, slush sl...@centrum.cz wrote:
AFAIK the only protection is SSL + certificate validation on client side.
However certificate revocation and updates in miners are
On Friday, August 08, 2014 12:29:31 AM slush wrote:
AFAIK the only protection is SSL + certificate validation on client side.
However certificate revocation and updates in miners are pain in the ass,
that's why majority of pools (mine including) don't want to play with
that...
Certificate
the only protection is SSL + certificate validation on client side.
However certificate revocation and updates in miners are pain in the ass,
that's why majority of pools (mine including) don't want to play with
that...
Another solution which would have less overhead would be to implement
Although 140 BTC sounds scary, actually it was very minor issue and most of
miners aren't even aware about it.
TLS would probably make the attack harder, that's correct. However if
somebody controls ISP routers, then MITM with TLS is harder, yet possible.
slush
On Fri, Aug 8, 2014 at 3:07 AM,
13 matches
Mail list logo
