* Re: [Bitcoin-development] Miners MiTM
2014-08-08 0:29 ` slush
@ 2014-08-08 0:37 ` Christopher Franko
2014-08-08 1:07 ` Pedro Worcel
2014-08-08 1:01 ` Luke Dashjr
` (2 subsequent siblings)
3 siblings, 1 reply; 16+ messages in thread
From: Christopher Franko @ 2014-08-08 0:37 UTC (permalink / raw)
Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 2575 bytes --]
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 <slush@centrum•cz> 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...
>
> slush
>
>
> On Fri, Aug 8, 2014 at 1:45 AM, Luke Dashjr <luke@dashjr•org> 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 BGP protocol to be in a
>> position
>> > where they can intercept the miner traffic. The concerning point is that
>> > they seem to be having some degree of success in their endeavour and
>> > earning profits from it.
>> >
>> > I do not understand the impact of this (I don't know much about BGP, the
>> > mining protocol nor anything else, really), but I thought it might be
>> worth
>> > putting it up here.
>>
>> This is old news; both BFGMiner and Eloipool were hardened against it a
>> long
>> time ago (although no Bitcoin pools have deployed it so far). I'm not
>> aware of
>> any actual case of it being used against Bitcoin, though - the target has
>> always been scamcoins.
>>
>>
>> ------------------------------------------------------------------------------
>> Infragistics Professional
>> Build stunning WinForms apps today!
>> Reboot your WinForms applications with our WinForms controls.
>> Build a bridge from your legacy apps to the future.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 4031 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Bitcoin-development] Miners MiTM
2014-08-08 0:37 ` Christopher Franko
@ 2014-08-08 1:07 ` Pedro Worcel
2014-08-08 2:22 ` slush
0 siblings, 1 reply; 16+ messages in thread
From: Pedro Worcel @ 2014-08-08 1:07 UTC (permalink / raw)
To: Christopher Franko; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 4354 bytes --]
> 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
something akin to what openssh does. The OpenSSH client stores a
certificate fingerprint, which is then verified automatically upon further
connections to the server.
The initial connection needs to be verified manually by the operator,
though.
> 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. This, combined with your concern about up to date
certs/revokes/etc, is why BFGMiner defaults to TLS without cert checking for
stratum.
Seems to me that it would correctly mitigate the attack mentioned in the
wired article. I am surprised that miners are not worried about losing
their profits, I would personally be quite annoyed.
2014-08-08 12:37 GMT+12:00 Christopher Franko <chrisjfranko@gmail•com>:
> 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 <slush@centrum•cz> 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...
>>
>> slush
>>
>>
>> On Fri, Aug 8, 2014 at 1:45 AM, Luke Dashjr <luke@dashjr•org> 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 BGP protocol to be in a
>>> position
>>> > where they can intercept the miner traffic. The concerning point is
>>> that
>>> > they seem to be having some degree of success in their endeavour and
>>> > earning profits from it.
>>> >
>>> > I do not understand the impact of this (I don't know much about BGP,
>>> the
>>> > mining protocol nor anything else, really), but I thought it might be
>>> worth
>>> > putting it up here.
>>>
>>> This is old news; both BFGMiner and Eloipool were hardened against it a
>>> long
>>> time ago (although no Bitcoin pools have deployed it so far). I'm not
>>> aware of
>>> any actual case of it being used against Bitcoin, though - the target has
>>> always been scamcoins.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Infragistics Professional
>>> Build stunning WinForms apps today!
>>> Reboot your WinForms applications with our WinForms controls.
>>> Build a bridge from your legacy apps to the future.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists•sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 6725 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Miners MiTM
2014-08-08 1:07 ` Pedro Worcel
@ 2014-08-08 2:22 ` slush
0 siblings, 0 replies; 16+ messages in thread
From: slush @ 2014-08-08 2:22 UTC (permalink / raw)
To: Pedro Worcel; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 546 bytes --]
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, Pedro Worcel <pedro@worcel•com> wrote:
>
> Seems to me that it would correctly mitigate the attack mentioned in the
> wired article. I am surprised that miners are not worried about losing
> their profits, I would personally be quite annoyed.
>
>
[-- Attachment #2: Type: text/html, Size: 1102 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Miners MiTM
2014-08-08 0:29 ` slush
2014-08-08 0:37 ` Christopher Franko
@ 2014-08-08 1:01 ` Luke Dashjr
2014-08-08 9:53 ` Mike Hearn
2014-08-08 3:18 ` Jeff Garzik
2014-08-08 9:42 ` Mike Hearn
3 siblings, 1 reply; 16+ messages in thread
From: Luke Dashjr @ 2014-08-08 1:01 UTC (permalink / raw)
To: slush; +Cc: bitcoin-development
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 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. This, combined with your concern about up to date
certs/revokes/etc, is why BFGMiner defaults to TLS without cert checking for
stratum.
Luke
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Miners MiTM
2014-08-08 1:01 ` Luke Dashjr
@ 2014-08-08 9:53 ` Mike Hearn
2014-08-08 18:21 ` Jeff Garzik
0 siblings, 1 reply; 16+ messages in thread
From: Mike Hearn @ 2014-08-08 9:53 UTC (permalink / raw)
To: Luke Dashjr; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 566 bytes --]
>
> 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 client TCP stack when it
discovers the server doesn't know about the connection anymore?
TLS without cert validation defeats the point, you can still be connected
to a MITM at any point by anyone who can simply interrupt or corrupt the
stream, forcing a reconnect.
[-- Attachment #2: Type: text/html, Size: 849 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Miners MiTM
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
0 siblings, 2 replies; 16+ messages in thread
From: Jeff Garzik @ 2014-08-08 18:21 UTC (permalink / raw)
To: Mike Hearn; +Cc: bitcoin-development
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 <mike@plan99•net> wrote:
>> 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 client TCP stack when it
> discovers the server doesn't know about the connection anymore?
>
> TLS without cert validation defeats the point, you can still be connected to
> a MITM at any point by anyone who can simply interrupt or corrupt the
> stream, forcing a reconnect.
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Miners MiTM
2014-08-08 18:21 ` Jeff Garzik
@ 2014-08-08 18:27 ` Luke Dashjr
2014-08-08 18:34 ` Laszlo Hanyecz
1 sibling, 0 replies; 16+ messages in thread
From: Luke Dashjr @ 2014-08-08 18:27 UTC (permalink / raw)
To: Jeff Garzik; +Cc: bitcoin-development
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 thought for GBT2 a while ago was to use simple ECDSA signatures for
messages. It'd be nice to use the same as Bitcoin, but then we'd hit problems
with RedHat/Fedora legal being stupid. :(
Luke
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Miners MiTM
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
1 sibling, 1 reply; 16+ messages in thread
From: Laszlo Hanyecz @ 2014-08-08 18:34 UTC (permalink / raw)
To: Jeff Garzik; +Cc: bitcoin-development
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 authenticate because every client has a different password they expect from the server, so they won't do work for you. MITM on the server can capture the exchange but CHAP protects against replay.
https://en.wikipedia.org/wiki/Challenge-Handshake_Authentication_Protocol
-Laszlo
On Aug 8, 2014, at 6:21 PM, Jeff Garzik <jgarzik@bitpay•com> 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.
>
>
> On Fri, Aug 8, 2014 at 5:53 AM, Mike Hearn <mike@plan99•net> wrote:
>>> 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 client TCP stack when it
>> discovers the server doesn't know about the connection anymore?
>>
>> TLS without cert validation defeats the point, you can still be connected to
>> a MITM at any point by anyone who can simply interrupt or corrupt the
>> stream, forcing a reconnect.
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Miners MiTM
2014-08-08 18:34 ` Laszlo Hanyecz
@ 2014-08-09 12:15 ` Sergio Lerner
0 siblings, 0 replies; 16+ messages in thread
From: Sergio Lerner @ 2014-08-09 12:15 UTC (permalink / raw)
To: bitcoin-development
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 not the miner server, so the worst DoS would be
preventing new miners to join the pool, which is not very often.
The MAC key can be provided directly by the miner. And the pool
associates the MAC key with a Bitcoin public address.
The overhead would be minimal.
-Sergio.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Miners MiTM
2014-08-08 0:29 ` slush
2014-08-08 0:37 ` Christopher Franko
2014-08-08 1:01 ` Luke Dashjr
@ 2014-08-08 3:18 ` Jeff Garzik
2014-08-08 9:42 ` Mike Hearn
3 siblings, 0 replies; 16+ messages in thread
From: Jeff Garzik @ 2014-08-08 3:18 UTC (permalink / raw)
To: slush; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 2831 bytes --]
You don't necessarily need the heavy weight of SSL.
You only need digitally signed envelopes between miner and pool[1].
[1] Unless the pool is royally stupid and will somehow credit miner B, if
miner B provides to the pool a copy of miner A's work.
On Thu, Aug 7, 2014 at 8:29 PM, slush <slush@centrum•cz> 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...
>
> slush
>
>
> On Fri, Aug 8, 2014 at 1:45 AM, Luke Dashjr <luke@dashjr•org> 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 BGP protocol to be in a
>> position
>> > where they can intercept the miner traffic. The concerning point is that
>> > they seem to be having some degree of success in their endeavour and
>> > earning profits from it.
>> >
>> > I do not understand the impact of this (I don't know much about BGP, the
>> > mining protocol nor anything else, really), but I thought it might be
>> worth
>> > putting it up here.
>>
>> This is old news; both BFGMiner and Eloipool were hardened against it a
>> long
>> time ago (although no Bitcoin pools have deployed it so far). I'm not
>> aware of
>> any actual case of it being used against Bitcoin, though - the target has
>> always been scamcoins.
>>
>>
>> ------------------------------------------------------------------------------
>> Infragistics Professional
>> Build stunning WinForms apps today!
>> Reboot your WinForms applications with our WinForms controls.
>> Build a bridge from your legacy apps to the future.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
[-- Attachment #2: Type: text/html, Size: 4417 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] Miners MiTM
2014-08-08 0:29 ` slush
` (2 preceding siblings ...)
2014-08-08 3:18 ` Jeff Garzik
@ 2014-08-08 9:42 ` Mike Hearn
2014-08-09 19:39 ` Troy Benjegerdes
3 siblings, 1 reply; 16+ messages in thread
From: Mike Hearn @ 2014-08-08 9:42 UTC (permalink / raw)
To: slush; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 684 bytes --]
>
> 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.
[-- Attachment #2: Type: text/html, Size: 1006 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Bitcoin-development] Miners MiTM
2014-08-08 9:42 ` Mike Hearn
@ 2014-08-09 19:39 ` Troy Benjegerdes
0 siblings, 0 replies; 16+ messages in thread
From: Troy Benjegerdes @ 2014-08-09 19:39 UTC (permalink / raw)
To: Mike Hearn; +Cc: bitcoin-development
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.
^ permalink raw reply [flat|nested] 16+ messages in thread