summaryrefslogtreecommitdiff
path: root/f6/a0090eb8a5ebe037a84289da4386318e84631f
blob: d9760299b8a7aca91ccc75d2ecccf887fad0d8bf (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1XBarb-0003SQ-Vc
	for bitcoin-development@lists.sourceforge.net;
	Mon, 28 Jul 2014 02:40:35 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.154 as permitted sender)
	client-ip=62.13.148.154; envelope-from=pete@petertodd.org;
	helo=outmail148154.authsmtp.co.uk; 
Received: from outmail148154.authsmtp.co.uk ([62.13.148.154])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1XBara-0006hy-40 for bitcoin-development@lists.sourceforge.net;
	Mon, 28 Jul 2014 02:40:35 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
	by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s6S2eRjh064456;
	Mon, 28 Jul 2014 03:40:27 +0100 (BST)
Received: from savin (75-119-251-161.dsl.teksavvy.com [75.119.251.161])
	(authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s6S2eMRF074922
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Mon, 28 Jul 2014 03:40:24 +0100 (BST)
Date: Sun, 27 Jul 2014 22:40:30 -0400
From: Peter Todd <pete@petertodd.org>
To: Jeremy <jlrubin@MIT.EDU>
Message-ID: <20140728024030.GA17724@savin>
References: <CAD5xwhhKKooGBfSY3nZzMmS=3WD=EdX9FQ7mZtQL3fkikuwyLg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/"
Content-Disposition: inline
In-Reply-To: <CAD5xwhhKKooGBfSY3nZzMmS=3WD=EdX9FQ7mZtQL3fkikuwyLg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 873253ba-1600-11e4-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aQdMdAoUEkAYAgsB AmIbW1deVF17W2Y7 bA9PbARUfEhLXhtr
	VklWR1pVCwQmQhpi BEtjMG9ycAFPenw+ ZEJrWnAVVEN5d0N+
	EB9JFGsGZXphaTUb TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL
	NQ4vNDcwO3BTJTpY RgYVKF8UXXNDNzQ6 QAoHFDErDAUhTj88
	IlQaLURUGkEdPw07 OlAsQU4ZNRBaDQta DiMFKi5FLF4AQWI3 FwpUU08VeAAA
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1XBara-0006hy-40
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>, alex@stamos.org
Subject: Re: [Bitcoin-development] Abnormally Large Tor node accepting only
 Bitcoin traffic
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 28 Jul 2014 02:40:36 -0000


--TB36FDmn/VVEgNH/
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 27, 2014 at 10:12:11PM -0400, Jeremy wrote:
> Hey,
>=20
> 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.
>=20
> http://torstatus.blutmagie.de/router_detail.php?FP=3D0d6d2caafbb32ba85ee5=
162395f610ae42930124
>=20
> 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.
>=20
> What we know so far:
>=20
> - 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=E2=82=AC/mo with 50TB of t=
raffic

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

--=20
'peter'[:-1]@petertodd.org
0000000000000000201d505432d708aa2edb656f6fe34d686b37d4747e5ff389

--TB36FDmn/VVEgNH/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJT1bgYXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAyMDFkNTA1NDMyZDcwOGFhMmVkYjY1NmY2ZmUzNGQ2ODZi
MzdkNDc0N2U1ZmYzODkvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsTvAf/TDD8g1AwmIOFZbVFjodMcYIh
FufBmvANOENBX3yzvXaYgDxCr+uPxkX/m/LkarulqyKpxtIlkLTc18biq/Jh8XON
3SULIdIN/vH5Y3aXT3qhSoxXYGeOGnjOFSvXYuNAsGYW5CiD6mijmeD0g7mgLjdv
QzY9dwnkPIFMD7qmboJL1mj42JnQYVRznDymOwKdsMJ3gDiroCWmQqpJxTfTAbxz
0Byw9w1lgslNxhK5NfVcSwl0D2pmD+7MhAcCwzUqPc7qqYMjbteecY0GRSmvX+O7
au1srQMNSOh0Q4aixfkGHWeE2vRP/VhBiCOrRzIDva2T4Engrb/jYr7vHZXgpQ==
=kW1W
-----END PGP SIGNATURE-----

--TB36FDmn/VVEgNH/--