Peter Todd [ARCHIVE] on Nostr: š Original date posted:2014-07-27 š Original message:On Sun, Jul 27, 2014 at ...
š
Original date posted:2014-07-27
š Original message:On Sun, Jul 27, 2014 at 10:12:11PM -0400, Jeremy wrote:
> Hey,
>
> There is a potential network exploit going on. In the last three days, a
> node (unnamed) came online and is now processing the most traffic out of
> any tor node -- and it is mostly plaintext Bitcoin traffic.
>
> http://torstatus.blutmagie.de/router_detail.php?FP=0d6d2caafbb32ba85ee5162395f610ae42930124
>
> Alex Stamos (cc'ed) and I have been discussing on twitter what this could
> mean, wanted to raise it to the attention of this group for discussion.
>
> What we know so far:
>
> - Only port 8333 is open
> - The node has been up for 3 days, and is doing a lot of bandwidth, mostly
> plaintext Bitcoin traffic
> - This is probably pretty expensive to run? Alex suggests that the most
> expensive server at the company hosting is 299ā¬/mo with 50TB of traffic
Boring explanation: some mining pool wants to get a lower orphan rate by
connecting to the whole network simultaneously and has cleverly setup
their node as a Tor exit node to get some plausible deniability.
Of course, reducing orphan rates is indistinguishable from a sybil
attack; in general setting up such a node can be plausible deniability
cover for any type of attack. One possibility would be to sybil attack
the network to do logging; another would be DoS attacks. For the latter
we're pretty vulnerable to the Bloom IO attack(1). The former attack is
possible too, though I'd expect an attacker to want to do it in a less
obvious way and run more than one node. Also running one big Tor node is
less than ideal as it won't accept incoming connections, which lets you
attack SPV clients. Finally note how you can plausibly conduct the
attack directly from the node itself without bothering to actually use
the Tor network.
Anyway, just goes to show that we need to implement better incoming
connection limiting. gmaxwell has a good scheme with interactive
proof-of-memory - where's your latest writeup?
1) https://github.com/petertodd/bloom-io-attack
--
'peter'[:-1]@petertodd.org
0000000000000000201d505432d708aa2edb656f6fe34d686b37d4747e5ff389
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140727/95df7e88/attachment.sig>;
š Original message:On Sun, Jul 27, 2014 at 10:12:11PM -0400, Jeremy wrote:
> Hey,
>
> There is a potential network exploit going on. In the last three days, a
> node (unnamed) came online and is now processing the most traffic out of
> any tor node -- and it is mostly plaintext Bitcoin traffic.
>
> http://torstatus.blutmagie.de/router_detail.php?FP=0d6d2caafbb32ba85ee5162395f610ae42930124
>
> Alex Stamos (cc'ed) and I have been discussing on twitter what this could
> mean, wanted to raise it to the attention of this group for discussion.
>
> What we know so far:
>
> - Only port 8333 is open
> - The node has been up for 3 days, and is doing a lot of bandwidth, mostly
> plaintext Bitcoin traffic
> - This is probably pretty expensive to run? Alex suggests that the most
> expensive server at the company hosting is 299ā¬/mo with 50TB of traffic
Boring explanation: some mining pool wants to get a lower orphan rate by
connecting to the whole network simultaneously and has cleverly setup
their node as a Tor exit node to get some plausible deniability.
Of course, reducing orphan rates is indistinguishable from a sybil
attack; in general setting up such a node can be plausible deniability
cover for any type of attack. One possibility would be to sybil attack
the network to do logging; another would be DoS attacks. For the latter
we're pretty vulnerable to the Bloom IO attack(1). The former attack is
possible too, though I'd expect an attacker to want to do it in a less
obvious way and run more than one node. Also running one big Tor node is
less than ideal as it won't accept incoming connections, which lets you
attack SPV clients. Finally note how you can plausibly conduct the
attack directly from the node itself without bothering to actually use
the Tor network.
Anyway, just goes to show that we need to implement better incoming
connection limiting. gmaxwell has a good scheme with interactive
proof-of-memory - where's your latest writeup?
1) https://github.com/petertodd/bloom-io-attack
--
'peter'[:-1]@petertodd.org
0000000000000000201d505432d708aa2edb656f6fe34d686b37d4747e5ff389
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140727/95df7e88/attachment.sig>;