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
146
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1TLQOW-0006yZ-Bw
for bitcoin-development@lists.sourceforge.net;
Tue, 09 Oct 2012 03:22:08 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.175 as permitted sender)
client-ip=209.85.223.175; envelope-from=gmaxwell@gmail.com;
helo=mail-ie0-f175.google.com;
Received: from mail-ie0-f175.google.com ([209.85.223.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TLQOV-00088A-Er
for bitcoin-development@lists.sourceforge.net;
Tue, 09 Oct 2012 03:22:08 +0000
Received: by mail-ie0-f175.google.com with SMTP id c13so11466398ieb.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 08 Oct 2012 20:22:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.47.227 with SMTP id g3mr440066ign.5.1349752921762; Mon, 08
Oct 2012 20:22:01 -0700 (PDT)
Received: by 10.64.34.4 with HTTP; Mon, 8 Oct 2012 20:22:01 -0700 (PDT)
In-Reply-To: <CANEZrP0bx7c1sm+9o6iXx_OnSdRH6a0jRNQcRb2Z3qbf0KFKiw@mail.gmail.com>
References: <CAAS2fgTVp7PhdJMfz-huyOsp=6Ca9wH6cVkedMgntXnK+ZpDXg@mail.gmail.com>
<CANEZrP0bx7c1sm+9o6iXx_OnSdRH6a0jRNQcRb2Z3qbf0KFKiw@mail.gmail.com>
Date: Mon, 8 Oct 2012 23:22:01 -0400
Message-ID: <CAAS2fgQjeSBJGOr+qH7PQpTB5cx1rdaPCC2e=2J7OG=5Pby5GA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.3 (-)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.3 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1TLQOV-00088A-Er
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>,
electrum.desktop@gmail.com
Subject: Re: [Bitcoin-development] Electrum security model concerns
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: Tue, 09 Oct 2012 03:22:08 -0000
On Mon, Oct 8, 2012 at 7:52 AM, Mike Hearn <mike@plan99.net> wrote:
> I don't think it's worth worrying about this too much right now. In
> future the software end users and merchants use will diverge
> significantly.
Electrum also has a daemon for merchants. Considering the dislike of
Java that exist reflexively in much of the non-java community and the
greater ease of deployment and the integration of type-2 split key
management, I wouldn't be surprised if it became quite popular
quickly especially if the status quo of failing to disclose and
discuss the security limitations of the client continues.
What I've found is that even fairly sophisticated bitcoin participants
are actually unaware of the security implications=E2=80=94 not just of thin
clients architecturally but of electrum specifically. I think even
you may find my findings of the latter a bit surprising.
Generally for thin clients=E2=80=94 a lying server can make clients think
they've received confirmed payments they haven't, and unless the
client is constructed to be a bit less thin a lying server can lie
about input values and cause think clients to spend large values to
fees. Servers can also monitor clients and deanonymize them and
selectively deny service to particular clients or transactions. Thin
clients must trust their servers to be available, and to not perform
these attacks. Users can use tools like tor to reduce the privacy
attacks, but doing so inhibits having a trust relationship to protect
against the other attacks. And none of these attacks leave
cryptographic proof of their existence, so a victim can't convince the
public of a server's treachery. Us experts know about these risks, but
I don't think the general users do.
But thats not the limit of it=E2=80=94 It seems some people believe Electr=
um
does majority quorum between servers, complicating attacks arising
from the fact that today users virtually never have a reason to trust
their server operators. This isn't true=E2=80=94 it connect to one at a ti=
me.
(And sibyl attacks would make that pretty weak protection even if it
did that, as someone could use a a botnet to run tens of thousands of
'servers' (really proxies)).
Beyond that the protocol between the clients and servers is
unauthenticated cleartext JSON in TCP. So any network advisory with
access to the network near the server has the same power to attack as
the server operator... and one near the client has the same power to
attack as the sum of all the server operators. A passive attacker
near the client has full deanonymization power.
But I don't even know if any of these limitations matter much=E2=80=94 The
electrum client instantly displays unconfirmed transactions and allows
users to spend them. The default user interface gives _no_ indication
that the payment is unconfirmed. There is a "pro" mode, that shows
'processing' for unconfirmed transactions... but it looks as final as
it ever will be once it gets a single confirm. Only the most cautious
and well informed users would open the pro interface and right click
and select details to see the count=E2=80=94 and even then there is no
guidance on what numbers are good (beyond '1'). So I suspect people
can probably rob typical electrum users (including electrum running
merchants) without actually using any of the above.
When a thin client is willing to provide arbitrary features like
showing unconfirmed payments and simplified UI without regard to
security it removes the functional advantage of running more secure
software like SPV and various degrees of full node... the only
motivation is security, and it's not much of a motivation when the
risks aren't even disclosed.
...and I haven't even gotten into delving into what kind of attacks
are possible due to deeper implementation specifics.
But I do share your view that people will migrate to stronger client
models in the future=E2=80=94 but I don't agree that it will be due to thos=
e
clients improving (though they will improve), it will be because
people will know that they provide better security and will choose
them for that reason.
My only question is will they know this because we as a community and
the authors of the thin clients provided clear explanations and
appropriate caution, or will it be because they're getting robbed
blind, producing a bunch of bad press for thin clients in particular
and Bitcoin generally?
|
