summaryrefslogtreecommitdiff
path: root/22/b094fbf1e4fed88228bf1b5d3e807f8694c23c
blob: 54611b9d2fcad649cd30b7ec394e4689fec929d2 (plain)
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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1VOnWo-00018M-Mg
	for bitcoin-development@lists.sourceforge.net;
	Wed, 25 Sep 2013 11:45:10 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.47 as permitted sender)
	client-ip=209.85.214.47; envelope-from=mh.in.england@gmail.com;
	helo=mail-bk0-f47.google.com; 
Received: from mail-bk0-f47.google.com ([209.85.214.47])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1VOnWn-0005SE-FJ
	for bitcoin-development@lists.sourceforge.net;
	Wed, 25 Sep 2013 11:45:10 +0000
Received: by mail-bk0-f47.google.com with SMTP id mx12so2175880bkb.6
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 25 Sep 2013 04:45:03 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.205.65.78 with SMTP id xl14mr27180952bkb.1.1380109502870;
	Wed, 25 Sep 2013 04:45:02 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.204.237.74 with HTTP; Wed, 25 Sep 2013 04:45:02 -0700 (PDT)
In-Reply-To: <l1uhld$d68$1@ger.gmane.org>
References: <CABsx9T0Ly67ZNJhoRQk0L9Q0-ucq3e=24b5Tg6GRKspRKKtP-g@mail.gmail.com>
	<521298F0.20108@petersson.at>
	<CABsx9T3b--tfUmaxJxsXyM2f3Cw4M1oX1nX8o9WkW_haBmLctA@mail.gmail.com>
	<CANEZrP2BOWk4FOUx4eVHvXmdSgx3zo_o18J8YBi2Uc_WkBAXKA@mail.gmail.com>
	<CANEZrP0H9TVfQ3AGv6aBmS1DUa6MTWhSFAN1Jo4eimBEBQhPZw@mail.gmail.com>
	<CABsx9T0TQ6Gg=muNP-rCZxan8_nAqeJt6ErYVOfnLJKrsLs81w@mail.gmail.com>
	<CANEZrP2V72+-m-FOCsW3C2GBO7+=-0casKadeHncmNTYjyqJRA@mail.gmail.com>
	<l1udst$uos$1@ger.gmane.org>
	<CANEZrP03KsGHvGqcNT1Qs6qkJ4i050CPjwvGqTRRhbdkgMf_dA@mail.gmail.com>
	<l1uhld$d68$1@ger.gmane.org>
Date: Wed, 25 Sep 2013 13:45:02 +0200
X-Google-Sender-Auth: 2UzFsEBleQx_8xflDrbHRJmhJJk
Message-ID: <CANEZrP2ZbSUvNk+0bHCWw40r00D8ja-crrZPjvN0mgG+NaD52w@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: multipart/alternative; boundary=bcaec5430d4eabacd604e733c80d
X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	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
X-Headers-End: 1VOnWn-0005SE-FJ
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
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: Wed, 25 Sep 2013 11:45:10 -0000

--bcaec5430d4eabacd604e733c80d
Content-Type: text/plain; charset=UTF-8

On Wed, Sep 25, 2013 at 1:33 PM, Andreas Schildbach
<andreas@schildbach.de>wrote:

> Why do you think that? Of course, I would skip the certificate, as its
> unnecessary if you see your partner in person.
>

OK, it might fit if you don't use any of the features the protocol provides
:) You can try it here:

https://bitcoincore.org/~gavin/createpaymentrequest.php


> HTTPS trust is utterly broken unless you fix it by adding the
>
certificate or a fingerprint to the QR code.
>

It's not "utterly broken", that's over-dramatic. It's just the best that
can be done with todays technology. I wrote about the SSL PKI and how it's
being upgraded here:

https://bitcointalk.org/index.php?topic=300809.0

If you're thinking about governments and so on subverting CA's, then there
is a plan for handling that (outside the Bitcoin world) called certificate
transparency which is being implemented now.

Now when you are getting a QR code from the web, it's already being served
over HTTPS. So if you're up against an attacker who can break a CA in order
to steal your money, then you already lose, the QRcode itself as MITMd.

In the Bluetooth case we might have to keep the address around and use it
to do ECDHE or something like that. The current BT support doesn't need
that because it's just blasting out a tx, the entire protocol is write
only. Once it's reading data as well then it'll need a custom security
layer.

--bcaec5430d4eabacd604e733c80d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Sep 25, 2013 at 1:33 PM, Andreas Schildbach <span =
dir=3D"ltr">&lt;<a href=3D"mailto:andreas@schildbach.de" target=3D"_blank">=
andreas@schildbach.de</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><=
div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im">Why do you think that? Of course, I woul=
d skip the certificate, as its<br>

unnecessary if you see your partner in person.</div></blockquote><div><br><=
/div><div>OK, it might fit if you don&#39;t use any of the features the pro=
tocol provides :) You can try it here:</div><div><br></div><div><a href=3D"=
https://bitcoincore.org/~gavin/createpaymentrequest.php">https://bitcoincor=
e.org/~gavin/createpaymentrequest.php</a></div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div class=3D"im">HTTPS trust is utterly =
broken unless you fix it by adding the<br>
</div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex"><div class=3D"im">
certificate or a fingerprint to the QR code. </div></blockquote><div><br></=
div><div>It&#39;s not &quot;utterly broken&quot;, that&#39;s over-dramatic.=
 It&#39;s just the best that can be done with todays technology. I wrote ab=
out the SSL PKI and how it&#39;s being upgraded here:</div>
<div><br></div><div><a href=3D"https://bitcointalk.org/index.php?topic=3D30=
0809.0">https://bitcointalk.org/index.php?topic=3D300809.0</a><br></div><di=
v><br></div><div>If you&#39;re thinking about governments and so on subvert=
ing CA&#39;s, then there is a plan for handling that (outside the Bitcoin w=
orld) called certificate transparency which is being implemented now.</div>
<div><br></div><div>Now when you are getting a QR code from the web, it&#39=
;s already being served over HTTPS. So if you&#39;re up against an attacker=
 who can break a CA in order to steal your money, then you already lose, th=
e QRcode itself as MITMd.</div>
<div><br></div><div>In the Bluetooth case we might have to keep the address=
 around and use it to do ECDHE or something like that. The current BT suppo=
rt doesn&#39;t need that because it&#39;s just blasting out a tx, the entir=
e protocol is write only. Once it&#39;s reading data as well then it&#39;ll=
 need a custom security layer.</div>
<div><br><div class=3D"im"><span style=3D"color:rgb(34,34,34)">=C2=A0</span=
></div></div></div></div></div>

--bcaec5430d4eabacd604e733c80d--