From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 To: Jeremy Message-ID: <20140728024030.GA17724@savin> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: 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 , 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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/--