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
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <drak@zikula.org>) id 1VplaQ-0005WC-3h
for bitcoin-development@lists.sourceforge.net;
Sun, 08 Dec 2013 21:08:22 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of zikula.org
designates 74.125.82.170 as permitted sender)
client-ip=74.125.82.170; envelope-from=drak@zikula.org;
helo=mail-we0-f170.google.com;
Received: from mail-we0-f170.google.com ([74.125.82.170])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VplaO-0003mf-Ou
for bitcoin-development@lists.sourceforge.net;
Sun, 08 Dec 2013 21:08:22 +0000
Received: by mail-we0-f170.google.com with SMTP id w61so2693022wes.29
for <bitcoin-development@lists.sourceforge.net>;
Sun, 08 Dec 2013 13:08:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=4RUDe+dXXSt2WSbkpRI/eESa+0wZZPjo2xTscQgIbik=;
b=FU87wqQWlFrXswwp33Vi+tb3HMWhcbsQyozf3ODCS1uxMo5iXpY9qn23oWcm1A5VvS
gYedIFGxrT95w6gCOHhs0pT+WYOPz4V0/kBRZ/opOFi/URK5ZUPq7ZwsQSlJkW1oIHxF
dO4UtL6Nwcvad79Jdl9NxLp7RqHsnX0BRp7tpp2IKJc+qbFCa9b3tAmMQ6zzxapKvwg2
/ZTLLWQR/5jkQx9EDRvTfOLpqWJ1fIcI/sxjcr8z4lz6SzS13Yo6o53RdrnVHJKzicoZ
Pu3xQGHUSVx1gdd9e7XfIpF0Zxhz92pP3UqPLV0jLFqmGvLYS9h4hq3+R27BmwgEea1N
jc6g==
X-Gm-Message-State: ALoCoQnqsKQ4A8x1vUCz7VlEghTWQQHH/HX3vP2LKztVLrwAWBfXBg3F0IxXclyaP0lqyauhvdjb
X-Received: by 10.180.9.74 with SMTP id x10mr11163003wia.56.1386536894294;
Sun, 08 Dec 2013 13:08:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.93.105 with HTTP; Sun, 8 Dec 2013 13:07:54 -0800 (PST)
In-Reply-To: <CAAS2fgT=0m=0-C+MNotUy6nqwcR-Y+YTNYrS8DZptMo5vCMRnA@mail.gmail.com>
References: <52A3C8A5.7010606@gmail.com>
<1795f3067ba3fcdd0caf978cc59ff024.squirrel@fruiteater.riseup.net>
<52A435EA.7090405@gmail.com> <201312081237.24473.luke@dashjr.org>
<CANAnSg2OrmQAcZ+cZdtQeADicH3U29QOgYPfP1AQhOMP6+P1wg@mail.gmail.com>
<CAAS2fgR0khyJxmz9c2Oc87hOFgiNuiPJuaeugGajdo_EcKEW9w@mail.gmail.com>
<CANAnSg2tep2VURmudfNModuJAryw8hfOj8Z8idVbt37keiZ8Lg@mail.gmail.com>
<CAAS2fgT=0m=0-C+MNotUy6nqwcR-Y+YTNYrS8DZptMo5vCMRnA@mail.gmail.com>
From: Drak <drak@zikula.org>
Date: Sun, 8 Dec 2013 21:07:54 +0000
Message-ID: <CANAnSg28awKbAGQS7-kNmenbU00XVB1gpN4c0A3dhGxaH4sxWw@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c245fa1197d904ed0c4738
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: bitcoin.org]
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1VplaO-0003mf-Ou
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Dedicated server for bitcoin.org,
your thoughts?
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: Sun, 08 Dec 2013 21:08:22 -0000
--001a11c245fa1197d904ed0c4738
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 8 December 2013 20:50, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> Sadly this isn't true: There are (many) CAs which will issue a
> certificate (apparently sometime within minutes, though last
> certificate I obtained took a couple hours total) to anyone who can
> respond to http (not https) requests on behalf of the domain from the
> perspective of the CA.
>
Simple verification relies on being able to answer the email sent to the
person in the whois records, or standard admin/webmaster@ addresses to
prove ownership of the domain. This is a good point to note -
bitcoin.orgshould not get a simple certificate, but one that requires
identify
verification for the person/org who is applying. They are more expensive.
> This means you can MITM the site, pass all traffic through except the
> HTTP request from the CA, and start intercepting once the CA has
> signed your certificate. This works because the CA does nothing to
> verify identity except check that the requester can control the site.
>
> If you'd like to me to demonstrate this attack for you I'd be willing=E2=
=80=94
> I can provide a proxy that passes on :80 and :443, run your traffic
> through it and I'll get a cert with your domain name.
>
You cannot MITM SSL connections - it will cause a browser warning.
I do not have the means, but it has been demonstrated some people are
performing BGP redirections, daily, and on a massive scale... and it's a
problem, because BGP was designed on implicit trust.
> I'm sorry for the tangent here=E2=80=94 I think this sub-discussion is re=
ally
> unrelated to having Bitcoin.org behind SSL=E2=80=94 but "someone is wrong=
on
> the internet", and its important to know that SSL hardly does anything
> to reduce the need to check the offline signatures on the binaries.
You are right that the CA system is not full-proof, one CA was caught
issuing a bogus certificate on purpose a while back, I forgot the name but
it resulted in CA certificate revokation and the entire company being
blacklisted from Firefox and Google Chrome forever - basically a summary
corporate execution. I personally imagine the CIA or other state actor
could just quietly buy up an already trusted CA and abuse them. But it's
clear, people are watching, and if a CA is caught once, that's the end of
their business forever: Firefox and Google demonstrated that. The strategy
is possibly too expensive and risky to carry off which is maybe why they
don't do it.
What has been noted with all the Snowden leaks, and with the Lavabit case,
the security agencies did not get bogus certificates issued, they still got
court orders, or other deception to get hold of the encryption certificates
of their targets instead of issuing their own so they could listen in.
The CA system is not full proof, but it is what we have. Similar arguments
have been made against the use of identity certificates for bitcoin, but
that hasnt stopped it's inclusion in the bitcoin payment protocol.
Anyway, I take your points, but this is an area I am quite passionate about
so it's important for me to be clear.
Regards,
Drak
--001a11c245fa1197d904ed0c4738
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 8=
December 2013 20:50, Gregory Maxwell <span dir=3D"ltr"><<a href=3D"mail=
to:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>></span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><span style=3D"color:rgb(3=
4,34,34)">Sadly this isn't true: There are (many) CAs which will issue =
a</span><br>
</div>
certificate (apparently sometime within minutes, though last<br>
certificate I obtained took a couple hours total) to anyone who can<br>
respond to http (not https) requests on behalf of the domain from the<br>
perspective of the CA.<br></blockquote><div><br></div><div>Simple verificat=
ion relies on being able to answer the email sent to the person in the whoi=
s records, or standard admin/webmaster@ addresses to prove ownership of the=
domain. This is a good point to note - <a href=3D"http://bitcoin.org">bitc=
oin.org</a> should not get a simple certificate, but one that requires iden=
tify verification for the person/org who is applying. They are more expensi=
ve.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
This means you can MITM the site, pass all traffic through except the<br>
HTTP request from the CA, and start intercepting once the CA has<br>
signed your certificate. This works because the CA does nothing to<br>
verify identity except check that the requester can control the site.<br>
<br>
If you'd like to me to demonstrate this attack for you I'd be willi=
ng=E2=80=94<br>
I can provide a proxy that passes on :80 and :443, run your traffic<br>
through it and I'll get a cert with your domain name.<br></blockquote><=
div><br></div><div>You cannot MITM SSL connections - it will cause a browse=
r warning.</div><div>I do not have the means, but it has been demonstrated =
some people are performing BGP redirections, daily, and on a massive scale.=
.. and it's a problem, because BGP was designed on implicit trust.</div=
>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
I'm sorry for the tangent here=E2=80=94 I think this sub-discussion is =
really<br>
unrelated to having Bitcoin.org behind SSL=E2=80=94 but "someone is wr=
ong on<br>
the internet", and its important to know that SSL hardly does anything=
<br>
to reduce the need to check the offline signatures on the binaries.</blockq=
uote><div><br></div><div>You are right that the CA system is not full-proof=
, one CA was caught issuing a bogus certificate on purpose a while back, I =
forgot the name but it resulted in CA certificate revokation and the entire=
company being blacklisted from Firefox and Google Chrome forever - basical=
ly a summary corporate execution. I personally imagine the CIA or other sta=
te actor could just quietly buy up an already trusted CA and abuse them. Bu=
t it's clear, people are watching, and if a CA is caught once, that'=
;s the end of their business forever: Firefox and Google demonstrated that.=
The strategy is possibly too expensive and risky to carry off which is may=
be why they don't do it.<br>
</div><div><br></div><div>What has been noted with all the Snowden leaks, a=
nd with the Lavabit case, the security agencies did not get bogus certifica=
tes issued, they still got court orders, or other deception to get hold of =
the encryption certificates of their targets instead of issuing their own s=
o they could listen in.</div>
<div><br></div><div>The CA system is not full proof, but it is what we have=
. Similar arguments have been made against the use of identity certificates=
for bitcoin, but that hasnt stopped it's inclusion in the bitcoin paym=
ent protocol.</div>
<div><br></div><div>Anyway, I take your points, but this is an area I am qu=
ite passionate about so it's important for me to be clear.</div><div><b=
r></div><div>Regards,</div><div><br></div><div>Drak</div></div></div></div>
--001a11c245fa1197d904ed0c4738--
|
