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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <drak@zikula.org>) id 1Vpjqd-0007rT-1o
for bitcoin-development@lists.sourceforge.net;
Sun, 08 Dec 2013 19:16:59 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of zikula.org
designates 74.125.82.169 as permitted sender)
client-ip=74.125.82.169; envelope-from=drak@zikula.org;
helo=mail-we0-f169.google.com;
Received: from mail-we0-f169.google.com ([74.125.82.169])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Vpjqb-00036U-Lr
for bitcoin-development@lists.sourceforge.net;
Sun, 08 Dec 2013 19:16:58 +0000
Received: by mail-we0-f169.google.com with SMTP id w61so2635682wes.0
for <bitcoin-development@lists.sourceforge.net>;
Sun, 08 Dec 2013 11:16:51 -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=u1REQH8xnPdiv9nnP2Raoar2G+4y8hBrAPj24TJ0LTc=;
b=j2fjlkis3VkMxtSIcxycaR0ZoimK/bjXao1Y0NH/PYMgGwnTgZbqSeoOK09LvUrbgX
LhopDttG9yQeWdLtxSSpsQSnt3g3tzLwMJLFeXS5ZESum0IeErbx51/ERluOqb845YTn
OUrpX5x9YUhUGmatw7FoGGZoY6bxFEtLG5POfWlDxGWMheXjuBOMOwa5vYQUp+QbQ0mi
IPkO1VJXnZvK0vROSZDKUdolFIz1MX6CH9v5q+TaMMwVYw+cjWPek9qjehSqgSwl/DIA
K2v11LBgdAxsms0nMtErYMm39KQ+3Y2NPL5KB3TyQ3j7CJBaXlgS5EEHJfMOYY2TYLR3
bSiw==
X-Gm-Message-State: ALoCoQnhotx5VkBnu/siVd3JtVdyv7vG5Z5DZj/31GPdhDSihRk9EUofnO3bLWg7O2Op2jc5MFeZ
X-Received: by 10.194.236.199 with SMTP id uw7mr2739481wjc.63.1386530211418;
Sun, 08 Dec 2013 11:16:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.93.105 with HTTP; Sun, 8 Dec 2013 11:16:31 -0800 (PST)
In-Reply-To: <201312081237.24473.luke@dashjr.org>
References: <52A3C8A5.7010606@gmail.com>
<1795f3067ba3fcdd0caf978cc59ff024.squirrel@fruiteater.riseup.net>
<52A435EA.7090405@gmail.com> <201312081237.24473.luke@dashjr.org>
From: Drak <drak@zikula.org>
Date: Sun, 8 Dec 2013 19:16:31 +0000
Message-ID: <CANAnSg2OrmQAcZ+cZdtQeADicH3U29QOgYPfP1AQhOMP6+P1wg@mail.gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=089e01493e44b8f1f504ed0ab856
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 SPF_PASS SPF: sender matches SPF record
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: dashjr.org]
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1Vpjqb-00036U-Lr
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 19:16:59 -0000
--089e01493e44b8f1f504ed0ab856
Content-Type: text/plain; charset=UTF-8
On 8 December 2013 12:37, Luke-Jr <luke@dashjr.org> wrote:
> Encryption is useless here. We want everyone to be able to download Bitcoin
> clients. Binaries on sourceforge are signed by multiple parties using
> gitian.
>
> > Decentralization:
> > So long as we actually use DNS, the website is centralized :( However,
> > its content isn't (can be forked on GitHub), but regarding the domain
> > name, there is not much we can do against this AFAIK.
>
> So long as someone has root (or a user that can modify it), the website is
> centralised. To really solve this, we would need a dedicated server that
> accepts commands only when signed by N-of-M parties, inside a cage locked
> by
> padlocks with keys held by independent parties, with a SSL certificate
> issued
> by an authority that has multiple parties watch it every step of the way
> into
> that server.
Malicious actors with root access to the server is another issue entirely.
Sure it's a problem, but it is not an argument not to have a properly
signed SSL certificate.
With out one, the exploit can be performed on routers to redirect traffic
through a third party alter the content of the site (like the links on
bitcoin.org to various wallet projects) and then onto the correct
destination. SSL at least mitigates that. For example it would be trivial
to impersonate Electrum's site or whatever, "change" the link on the fly
that appears on the trusted source bitcoin.org via BGP redirection. Now
users will be directed to the scammers site which could be identical except
for domain name and of course malicious binaries.
BGP redirection is a reality and can be exploited without much
expense/effort. MITM is a real world threat, not some theoretical
possibility - reports show it's happening on an unprecedented scale. SSL is
essential - that's a no-brainer. Sure other measures are important, but
without SSL there is almost no point to any of the other options.
SSL is so considered so important that the *HTTP 2.0 spec might be SSL
only*according to recent discussions at the W3C (
http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0625.html).
Drak
--089e01493e44b8f1f504ed0ab856
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 12:37, Luke-Jr <span dir=3D"ltr"><<a href=3D"mailto:luke@=
dashjr.org" target=3D"_blank">luke@dashjr.org</a>></span> wrote:<br><blo=
ckquote 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;paddi=
ng-left:1ex">
<div><span style=3D"color:rgb(34,34,34)">Encryption is useless here. We wan=
t everyone to be able to download Bitcoin</span><br></div>
clients. Binaries on sourceforge are signed by multiple parties using gitia=
n.<br>
<div><br>
> Decentralization:<br>
> So long as we actually use DNS, the website is centralized :( However,=
<br>
> its content isn't (can be forked on GitHub), but regarding the dom=
ain<br>
> name, there is not much we can do against this AFAIK.<br>
<br>
</div>So long as someone has root (or a user that can modify it), the websi=
te is<br>
centralised. To really solve this, we would need a dedicated server that<br=
>
accepts commands only when signed by N-of-M parties, inside a cage locked b=
y<br>
padlocks with keys held by independent parties, with a SSL certificate issu=
ed<br>
by an authority that has multiple parties watch it every step of the way in=
to<br>
that server.</blockquote><div><br></div><div>Malicious actors with root acc=
ess to the server is another issue entirely. Sure it's a problem, but i=
t is not an argument not to have a properly signed SSL certificate.</div>
<div><br></div><div>With out one, the exploit can be performed on routers t=
o redirect traffic through a third party alter the content of the site (lik=
e the links on <a href=3D"http://bitcoin.org" target=3D"_blank">bitcoin.org=
</a> to various wallet projects) and then onto the correct destination. SSL=
at least mitigates that. For example it would be trivial to impersonate El=
ectrum's site or whatever, "change" the link on the fly that =
appears on the trusted source <a href=3D"http://bitcoin.org" target=3D"_bla=
nk">bitcoin.org</a> via BGP redirection. Now users will be directed to the =
scammers site which could be identical except for domain name and of course=
malicious binaries.=C2=A0</div>
<div><br></div><div>BGP redirection is a reality and can be exploited witho=
ut much expense/effort. MITM is a real world threat, not some theoretical p=
ossibility - reports show it's happening on an unprecedented scale. SSL=
is essential - that's a no-brainer. Sure other measures are important,=
but without SSL there is almost no point to any of the other options.</div=
>
<div><br></div><div>SSL is so considered so important that the <u>HTTP 2.0 =
spec might be SSL only</u> according to recent discussions at the W3C (<a h=
ref=3D"http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0625.htm=
l">http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0625.html</a=
>).</div>
<div><br></div><div>
Drak<br></div><div>=C2=A0</div></div></div></div>
--089e01493e44b8f1f504ed0ab856--
|
