From: Troy Benjegerdes <hozer@hozed•org>
To: Mike Hearn <mike@plan99•net>
Cc: "bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Miners MiTM
Date: Sat, 9 Aug 2014 14:39:54 -0500 [thread overview]
Message-ID: <20140809193954.GI22640@nl.grid.coop> (raw)
In-Reply-To: <CANEZrP0fsojCdKUe0Yx6POJesyTbq4f41MPzFfhKWerFn0UJGw@mail.gmail.com>
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...
> >
>
> Why would miners need updates? If they implement the standard SSL
> infrastructure you can change certificates and keys without needing to
> update miners.
>
> Besides, when it comes to financial services SSL is essential, I'm kind of
> surprised it wasn't already used everywhere. I wouldn't use an online bank
> that didn't support SSL, I would see it as a a sign of serious problems.
> Heck I wouldn't even use webmail that didn't support SSL these days.
Because turning on SSL gives pool operators a way to hack your miners.
http://www.symantec.com/connect/blogs/openssl-patches-critical-vulnerabilities-two-months-after-heartbleed
Just because SSL is the answer for financial services regulated security
theatre, where fraud means you just roll-back the transaction, it does not
mean it is actually a good cryptographic solution.
There are far better mechanisms that could be implemented using ECDSA
keys (aka bitcoin addresses) to authenticate both miners and pools, but
the problem is there zero economic incentive to do so. As long as the
BGP/SSL/zero-day-of-the-week man-in-the middle fraud cost is lower than the
engineering cost to do some real cryptography and code audits, we'll keep
having new 'security patches' every couple of months.
next prev parent reply other threads:[~2014-08-09 19:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-07 23:02 Pedro Worcel
2014-08-07 23:45 ` Luke Dashjr
2014-08-08 0:29 ` slush
2014-08-08 0:37 ` Christopher Franko
2014-08-08 1:07 ` Pedro Worcel
2014-08-08 2:22 ` slush
2014-08-08 1:01 ` Luke Dashjr
2014-08-08 9:53 ` Mike Hearn
2014-08-08 18:21 ` Jeff Garzik
2014-08-08 18:27 ` Luke Dashjr
2014-08-08 18:34 ` Laszlo Hanyecz
2014-08-09 12:15 ` Sergio Lerner
2014-08-08 3:18 ` Jeff Garzik
2014-08-08 9:42 ` Mike Hearn
2014-08-09 19:39 ` Troy Benjegerdes [this message]
2014-08-09 19:31 ` Troy Benjegerdes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140809193954.GI22640@nl.grid.coop \
--to=hozer@hozed$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox