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
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
|
Return-Path: <vitteaymeric@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8C575BB3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Sep 2017 17:40:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5889B17E
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Sep 2017 17:40:58 +0000 (UTC)
Received: by mail-wm0-f43.google.com with SMTP id m127so876784wmm.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Sep 2017 10:40:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-transfer-encoding:content-language;
bh=W2AdboQXunb8FpuGGQBtQsnx/ZDkJK8vylKFcERcphg=;
b=iRs0qmK+M+fWjX29BTW5wdOb5prTEbXI0CSSIitZsuo4YPMV9fMwC9e1TKiiMahQ5G
fCs3Ra99g/kS3iEmT15ReNEC82zfxqILxF80I6W1WbhZlBeBz1+Lm1A3Cp9wSTHWT1Ih
w8h9KH8U7txc09F9n9DIxrJ2vUVVs5IuMzEI28WdsW2xXXDHW/SLC95TPl/NgZ9I87Bu
72E0PGLhWS7u4Go+kZWt4MNajPzUaO5sCqZIuEQ09VK8EFjE/POmeLWISXtg61Dknd9Q
/GE6r7EngdMMJXGobQMEJfBFmYzDpfeD1YfFcm/gckpgPGxx54+h6sC7RuBEXBX4ITNe
HJDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-transfer-encoding
:content-language;
bh=W2AdboQXunb8FpuGGQBtQsnx/ZDkJK8vylKFcERcphg=;
b=JLBYKQ79ml1k+VLB/21CHzfXyH9t9viv81s4nJuTfCZA3Oyy/vlVlPqIAI0qW2nlgU
fP3okKo9LN4gWRuXGHD22xgqr/Dz/gCDud5bOLiBrTZqdYhCMg0pzZ1zBYEEjDFhiflf
Z1dEoKr/qZLMRaz6EPFIb2N87Qf/AB9laQd/N35UE7PRkIm12a3UD55MhtL9ueIkeLHW
aGRMBZn0MzWAyrLShb3gsyxplnmxm/qcRxAP5YzJwnnvTE4tPAeUAlS3yobudqtRmP8P
C4uNxV8IyzUX96rS/1OoNNjVXcY3jTPtKbx+jpDwpWsBkGZBpDob8RHhXqIJp6S2zS2V
4+cA==
X-Gm-Message-State: AHPjjUhnGbvh6MPUKh4vIflQh/AF9yi835b5ecWDRLFoLmhQgJji0paz
M9QyMJXK0NpzwFrCRZcq8FqWCQ==
X-Google-Smtp-Source: AOwi7QCEYVNPQIGWjRz5L9SpgxUyjZ7VenFjcgOyqT6K+Xj7WCNzYsfPbVS4c0fuJAdqwUthU8bEcw==
X-Received: by 10.80.192.71 with SMTP id u7mr10983429edd.153.1506706856680;
Fri, 29 Sep 2017 10:40:56 -0700 (PDT)
Received: from ?IPv6:2a01:cb1d:5c:1600:9d6d:71b2:cb71:cb17?
([2a01:cb1d:5c:1600:9d6d:71b2:cb71:cb17])
by smtp.googlemail.com with ESMTPSA id
d2sm4897484ede.50.2017.09.29.10.40.55
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 29 Sep 2017 10:40:56 -0700 (PDT)
To: Tomas <tomas@tomasvdw.nl>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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>
<1506690843.2339068.1122431744.5A801943@webmail.messagingengine.com>
From: Aymeric Vitte <vitteaymeric@gmail.com>
Message-ID: <d0855fe8-03b2-4f71-9514-7c841396aaa8@gmail.com>
Date: Fri, 29 Sep 2017 19:40:00 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:52.0) Gecko/20100101
Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <1506690843.2339068.1122431744.5A801943@webmail.messagingengine.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: fr
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM
autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
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 17:40:59 -0000
Everybody knows that https is broken and insecure, and everybody knows
that it's still better than nothing
Just reacting here because there is worse: you are quoting Kraken, did
not check for Coinbase but Kraken is proxying all of its https traffic
via Cloudflare, including the API traffic
This is crazy but that's how things are, that's what everybody is doing,
that's what we have
The https principles are obsolete, the concept of certificates tied to a
domain is a complete stupidity, because there are no concept of domains
in bitcoin for example (and webrtc, Tor, bittorrent, p2p systems, etc)
and should evolve to something like certificates tied to an entityID
managed by something like a blockchain system, and not a stupid domain or CA
Therefore specifying things for bitcoin à la web is not a good idea,
browsers can do far better than standard/usual web, and the "like
everybody is doing" argument is not a valid one
Le 29/09/2017 à 15:14, Tomas via bitcoin-dev a écrit :
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
|
