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
|
Return-Path: <tomas@tomasvdw.nl>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 598B9910
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Sep 2017 13:14:06 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
[66.111.4.25])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C2D6D481
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Sep 2017 13:14:04 +0000 (UTC)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42])
by mailout.nyi.internal (Postfix) with ESMTP id C63722193A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Sep 2017 09:14:03 -0400 (EDT)
Received: from web5 ([10.202.2.215])
by compute2.internal (MEProxy); Fri, 29 Sep 2017 09:14:03 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=content-transfer-encoding:content-type
:date:from:in-reply-to:message-id:mime-version:references
:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=0YykWp
LJY2z7sb+Vwo1WIOyLc9tkUhnSr9/Ye9VqBjc=; b=j1Zm2vVfGtVJnlXwy9cVsj
KzbubD/oplbC528b/qHgCfS2db4gUXOOf/HFBC+uuQD4YNkLDF50XmCwFJasuZqI
Ddk9JfYuwzYpGRiv3KH+E0kM5kOGKpVRoSk1CSkQsvFQbujZnTN+AagdECUBS4kq
9MpZTab7pSaEYq5gXkCvsjMuOEmQFe27eFS+/tQS14raei3EIoobKzElfIwgb1fw
Y2itksj/a+96H5TVCrzqaRV71kD59+Qo4wcWDPqEfUnmy5TZ9A7U2VLqEkHWfqZ/
OnLZjvpMfMPdOZ7s3lMJCjk+dQVGrp039PF1W7+8pmwYEAJP6eiu7bjbNxSoMZ3g
==
X-ME-Sender: <xms:G0fOWf3VTm-XTEdzakeQULXQXlveAIMrHxKuEVFQBxA5GiPGUyErpA>
Received: by mailuser.nyi.internal (Postfix, from userid 99)
id A43489E2DE; Fri, 29 Sep 2017 09:14:03 -0400 (EDT)
Message-Id: <1506690843.2339068.1122431744.5A801943@webmail.messagingengine.com>
From: Tomas <tomas@tomasvdw.nl>
To: bitcoin-dev@lists.linuxfoundation.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-6cb49228
In-Reply-To: <20170929025538.GC12303@savin.petertodd.org>
References: <20170927160654.GA12492@savin.petertodd.org>
<oqihpf$5gc$1@blaine.gmane.org>
<B5DE4E92-C5B3-4C01-A148-E3C46C897323@sprovoost.nl>
<20170929025538.GC12303@savin.petertodd.org>
Date: Fri, 29 Sep 2017 15:14:03 +0200
X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
RCVD_IN_DNSWL_LOW autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 29 Sep 2017 15:24:12 +0000
Subject: Re: [bitcoin-dev] Why the BIP-72 Payment Protocol URI Standard is
Insecure Against MITM Attacks
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Sep 2017 13:14:06 -0000
On Fri, Sep 29, 2017, at 04:55, Peter Todd via bitcoin-dev wrote:
> The BIP-70 payment protocol used via BIP-72 URI's is insecure, as payment
> qr
> codes don't cryptographically commit to the identity of the merchant,
> which
> means a MITM attacker can redirect the payment if they can obtain a SSL
> cert
> that the wallet accepts.
By that reasoning, we also shouldn't go to https://coinbase.com or
https://kraken.com to buy any bitcoins? As a MITM can redirect the site
_if_ they obtain the coinbase or kraken certificate.
Obviously, HTTPS is secured under the assumption that certificates are
secure.
Using the payment protocol simply means paying to a secure endpoint (eg
https://tomasvdw.nl/pay) instead of an address.
> That wallet is also likely using an off-the-shelf SSL library,
> with
> nothing other than an infrequently updated set of root certificates to
> use to
> verify the certificate; your browser has access to a whole host of better
> technologies, such as HSTS pinning, certificate transparency, and
> frequently
> updated root certificate lists with proper revocation (see Symantec).
So we should not use HTTPS for secure transfer because the
implementation may not be good enough? This incorrectly conflates
implementation with specification. There is nothing stopping a developer
from using a proper implementation.
>
> As an ad-hoc, unstandardized, extension Android Wallet for Bitcoin at
> least
> supports a h= parameter with a hash commitment to what the payment
> request
> should be, and will reject the MITM attacker if that hash doesn't match.
> But
> that's not actually in the standard itself, and as far as I can tell has
> never
> been made into a BIP.
Currently it is widely used by merchants, but not yet for light clients
_receiving_ money. If it becomes more wide spread, it offers a range
of advantages as the bitcoin-address of the URI can and should be
deprecated (made impossible with "h="). A payment address just becomes a
secure endpoint.
This means no more address reuse is possible. Also, it drops the need
for mempool synchronization among non-miners, solely as a "notification"
mechanism. In addition it means light clients know exactly when a
transaction is coming in, so they can efficiently rely on client-side
filtering a small set of blocks, improving their privacy.
In my opinion, the payment protocol is key to scaling.
> As-is BIP-72 is very dangerous and should be depreciated, with a new BIP
> made
> to replace it.
Sorry, but maybe you could explain better how secure communication over
HTTPS is "very dangerous"? I think some websites would like to know :)
Tomas van der Wansem
bitcrust
|
