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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <ivan.pustogarov@uni.lu>) id 1XJUBZ-0000Ep-9i
for bitcoin-development@lists.sourceforge.net;
Mon, 18 Aug 2014 21:09:49 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of uni.lu
designates 158.64.76.33 as permitted sender)
client-ip=158.64.76.33; envelope-from=ivan.pustogarov@uni.lu;
helo=hercules.uni.lu;
Received: from hercules.uni.lu ([158.64.76.33])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XJUBX-0006Dp-AI
for bitcoin-development@lists.sourceforge.net;
Mon, 18 Aug 2014 21:09:49 +0000
X-IronPort-AV: E=Sophos;i="5.01,888,1400018400"; d="scan'208";a="48413953"
Date: Mon, 18 Aug 2014 23:02:57 +0200
From: Ivan Pustogarov <ivan.pustogarov@uni.lu>
To: Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <20140818210257.GB639@localhost.localdomain>
References: <20140818164543.GB31175@localhost.localdomain>
<CAAS2fgQZaDOtoh+_oaiZh6jMOacSuHbEM=vktBdThDP_7eRH0Q@mail.gmail.com>
<20140818183721.GD31175@localhost.localdomain>
<CAAS2fgQa1ZURn1M9-LBnSHsE5fHKdatrVbNJbd+E9JYQYH=wFw@mail.gmail.com>
<20140818203343.GA639@localhost.localdomain>
<CAAS2fgR5EEtevfKB2xKwExhtokb8naBH_PsLkJz3ZeJfeW6YFw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAAS2fgR5EEtevfKB2xKwExhtokb8naBH_PsLkJz3ZeJfeW6YFw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Originating-IP: [10.24.1.80]
X-Spam-Score: -2.2 (--)
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_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
-0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1XJUBX-0006Dp-AI
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Outbound connections rotation
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, 18 Aug 2014 21:09:49 -0000
For each neighbour, a Bitcoin peer keeps the history of addresses that
it forwarded to the neighbour. If an address was already forwarded
to a neighbour it is not retransmitted again.
An attacker can make a list of potential IP addresses of clients (say
an IP range of an ISP, or listen for addresses in the Bitcoin network
before the attack). Then she periodically "spams" the network with this list and
updates the address-forward history at each Bitcoin peer.
After each "spam" round, the attacker reconnects her connections to Bitcoin peers
and thus clears the retransmission history for her connections only.
As the result, when a NAT client connects to the network and advertises its
address, the addresses will propagate to the attacker's connections only.
On Mon, Aug 18, 2014 at 01:43:44PM -0700, Gregory Maxwell wrote:
> On Mon, Aug 18, 2014 at 1:33 PM, Ivan Pustogarov <ivan.pustogarov@uni.lu> wrote:
> > The attack I'm trying to address is described here: https://www.cryptolux.org/index.php/Bitcoin
> > It was discussed here: https://bitcointalk.org/index.php?topic=632124.0
> >
> > It uses the following observation. Each NATed client connects to the Bitcoin network
> > through 8 entry peers; he also advertises his public IP address to these peers which
> > allows an attacker to make the mapping <8-entry-peers, client-IP-address>.
>
> I'm afraid I'm losing you here. The node advertises himself to
> everyone he is connected to and in/or out, those nodes pass along
> those advertisements. When I receive an advertisement from a node I
> do not know how far away the advertised peers is, presumably I can
> accurately exclude it from being 0-hops— itself—) 1 or more should be
> indistinguishable. Is there a reason that they're distinguishable that
> I'm missing?
>
> Can you explain to me how you propose to produce this mapping?
--
Ivan
|
