* [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
@ 2013-12-08 1:17 Saïvann Carignan
2013-12-08 3:38 ` Odinn Cyberguerrilla
2013-12-08 16:08 ` Wladimir
0 siblings, 2 replies; 56+ messages in thread
From: Saïvann Carignan @ 2013-12-08 1:17 UTC (permalink / raw)
To: bitcoin-development
I would like to know what are your thoughts on moving bitcoin.org on a
dedicated server with a SSL certificate?
I am considering the idea more seriously, but I'd like some feedback
before taking steps.
Saïvann
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 1:17 [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts? Saïvann Carignan
@ 2013-12-08 3:38 ` Odinn Cyberguerrilla
2013-12-08 9:03 ` Saïvann Carignan
2013-12-08 10:00 ` Drak
2013-12-08 16:08 ` Wladimir
1 sibling, 2 replies; 56+ messages in thread
From: Odinn Cyberguerrilla @ 2013-12-08 3:38 UTC (permalink / raw)
To: bitcoin-development
Hello, re. the dedicated server for bitcoin.org idea, I have a few thoughts
1) I have commented in a blogpost of August 2013 at
https://odinn.cyberguerrilla.org/ with some thoughts relative to possible
issues with CA related to bitcoin.org - where I mentioned something
relative to the DigiCert certificate,
"DigiCert “may revoke a Certificate, without notice, for the reasons
stated in the CPS, including if DigiCert reasonably believes that” (…)
“Applicant is added to a government list of prohibited persons or entities
or is operating from a prohibited destination under the laws of the United
States” (…) “the Private Key associated with a Certificate was disclosed
or Compromised”"
In the same post I mentioned
"Bitcoin.org has no certificate, no encryption — a situation which has its
own obvious problems. Bitcoin.org currently sends users to download the
bitcoin-qt client from sourceforge. Sourceforge is encrypted and has a
certificate based on GeoTrust:
https://www.geotrust.com/resources/repository/legal/"
(Currently (Dec. 7, 2013) bitcoin.org shows as 'not verified' and 'not
encrypted' examining it in a cursory fashion w/ Chrome)
Not sure how this would work, but it would be nice to see the content at
bitcoin.org encrypted, of course, but also further decentralized? how many
mirrors are there of bitcoin.org - not sure, but a few things that come to
mind when thinking of this are Tahoe-LAFS and also .bit stuff (namecoin).
There are many ways to decentralize something but that is just something
that comes to mind.
This has been discussed at https://bitcointalk.org/index.php?topic=16312.0
('Is Bitcoin.org a weakness of bitcoin?) in the past and see also this
https://bitcointalk.org/index.php?topic=119652.0 which discusses mirroring
of certain content
Some things to think about.
> I would like to know what are your thoughts on moving bitcoin.org on a
> dedicated server with a SSL certificate?
>
> I am considering the idea more seriously, but I'd like some feedback
> before taking steps.
>
> Saïvann
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 3:38 ` Odinn Cyberguerrilla
@ 2013-12-08 9:03 ` Saïvann Carignan
2013-12-08 12:37 ` Luke-Jr
2013-12-08 10:00 ` Drak
1 sibling, 1 reply; 56+ messages in thread
From: Saïvann Carignan @ 2013-12-08 9:03 UTC (permalink / raw)
To: bitcoin-development
Forward secrecy:
I was definitively already interested in using this.
Binaries:
Sourceforge is not encrypted, actually. Although binaries hosting /
sharing could be a separate subject discussed later I think.
Revocation:
I guess we could just buy another SSL cert from another CA (I mean, if
that really happens). There's a few ones that are not US based.
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.
Saïvann
Le 2013-12-07 22:38, Odinn Cyberguerrilla a écrit :
> Hello, re. the dedicated server for bitcoin.org idea, I have a few thoughts
>
> 1) I have commented in a blogpost of August 2013 at
> https://odinn.cyberguerrilla.org/ with some thoughts relative to possible
> issues with CA related to bitcoin.org - where I mentioned something
> relative to the DigiCert certificate,
> "DigiCert “may revoke a Certificate, without notice, for the reasons
> stated in the CPS, including if DigiCert reasonably believes that” (…)
> “Applicant is added to a government list of prohibited persons or entities
> or is operating from a prohibited destination under the laws of the United
> States” (…) “the Private Key associated with a Certificate was disclosed
> or Compromised”"
> In the same post I mentioned
> "Bitcoin.org has no certificate, no encryption — a situation which has its
> own obvious problems. Bitcoin.org currently sends users to download the
> bitcoin-qt client from sourceforge. Sourceforge is encrypted and has a
> certificate based on GeoTrust:
> https://www.geotrust.com/resources/repository/legal/"
>
> (Currently (Dec. 7, 2013) bitcoin.org shows as 'not verified' and 'not
> encrypted' examining it in a cursory fashion w/ Chrome)
>
> Not sure how this would work, but it would be nice to see the content at
> bitcoin.org encrypted, of course, but also further decentralized? how many
> mirrors are there of bitcoin.org - not sure, but a few things that come to
> mind when thinking of this are Tahoe-LAFS and also .bit stuff (namecoin).
> There are many ways to decentralize something but that is just something
> that comes to mind.
>
> This has been discussed at https://bitcointalk.org/index.php?topic=16312.0
> ('Is Bitcoin.org a weakness of bitcoin?) in the past and see also this
> https://bitcointalk.org/index.php?topic=119652.0 which discusses mirroring
> of certain content
>
> Some things to think about.
>
>> I would like to know what are your thoughts on moving bitcoin.org on a
>> dedicated server with a SSL certificate?
>>
>> I am considering the idea more seriously, but I'd like some feedback
>> before taking steps.
>>
>> Saïvann
>>
>> ------------------------------------------------------------------------------
>> Sponsored by Intel(R) XDK
>> Develop, test and display web and hybrid apps with a single code base.
>> Download it for free now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 3:38 ` Odinn Cyberguerrilla
2013-12-08 9:03 ` Saïvann Carignan
@ 2013-12-08 10:00 ` Drak
2013-12-08 12:39 ` Luke-Jr
2013-12-08 16:51 ` Gregory Maxwell
1 sibling, 2 replies; 56+ messages in thread
From: Drak @ 2013-12-08 10:00 UTC (permalink / raw)
To: Odinn Cyberguerrilla; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 4489 bytes --]
There is really no excuse for not using an SSL certificate. Without one it
would be trivial for an attacker to change the contents of the page via
MITM.
Recent studies have shown MASSIVE abuse of the BGP routing protocol being
used to redirect websites through a third party.
This is not a theoretical attack, it's happening every single day on a
global scale and could be used to divert users to a rogue versions of
software.
It's just a matter of time... it will happen sooner or later given the
incentives it could bring...
Recent references:
http://www.theregister.co.uk/2013/11/22/net_traffic_redirection_attacks/
http://www.wired.com/threatlevel/2013/12/bgp-hijacking-belarus-iceland/
The only way to mitigate these MITMs is to use SSL.
Also it's about time we hosted the Bitcoin Qt software at Github. They have
a releases feature where you can upload a packaged release (see
https://github.com/blog/1547-release-your-software). There are also no
adverts (another privacy leak at the least) and many feel are more
trustworthy than Sourceforge: it also makes sense to have the downloads
where the source is developed.
Regards,
Drak
On 8 December 2013 03:38, Odinn Cyberguerrilla <
odinn.cyberguerrilla@riseup•net> wrote:
> Hello, re. the dedicated server for bitcoin.org idea, I have a few
> thoughts
>
> 1) I have commented in a blogpost of August 2013 at
> https://odinn.cyberguerrilla.org/ with some thoughts relative to possible
> issues with CA related to bitcoin.org - where I mentioned something
> relative to the DigiCert certificate,
> "DigiCert “may revoke a Certificate, without notice, for the reasons
> stated in the CPS, including if DigiCert reasonably believes that” (…)
> “Applicant is added to a government list of prohibited persons or entities
> or is operating from a prohibited destination under the laws of the United
> States” (…) “the Private Key associated with a Certificate was disclosed
> or Compromised”"
> In the same post I mentioned
> "Bitcoin.org has no certificate, no encryption — a situation which has its
> own obvious problems. Bitcoin.org currently sends users to download the
> bitcoin-qt client from sourceforge. Sourceforge is encrypted and has a
> certificate based on GeoTrust:
> https://www.geotrust.com/resources/repository/legal/"
>
> (Currently (Dec. 7, 2013) bitcoin.org shows as 'not verified' and 'not
> encrypted' examining it in a cursory fashion w/ Chrome)
>
> Not sure how this would work, but it would be nice to see the content at
> bitcoin.org encrypted, of course, but also further decentralized? how many
> mirrors are there of bitcoin.org - not sure, but a few things that come to
> mind when thinking of this are Tahoe-LAFS and also .bit stuff (namecoin).
> There are many ways to decentralize something but that is just something
> that comes to mind.
>
> This has been discussed at https://bitcointalk.org/index.php?topic=16312.0
> ('Is Bitcoin.org a weakness of bitcoin?) in the past and see also this
> https://bitcointalk.org/index.php?topic=119652.0 which discusses mirroring
> of certain content
>
> Some things to think about.
>
> > I would like to know what are your thoughts on moving bitcoin.org on a
> > dedicated server with a SSL certificate?
> >
> > I am considering the idea more seriously, but I'd like some feedback
> > before taking steps.
> >
> > Saïvann
> >
> >
> ------------------------------------------------------------------------------
> > Sponsored by Intel(R) XDK
> > Develop, test and display web and hybrid apps with a single code base.
> > Download it for free now!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists•sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
>
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 6648 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 9:03 ` Saïvann Carignan
@ 2013-12-08 12:37 ` Luke-Jr
2013-12-08 19:16 ` Drak
0 siblings, 1 reply; 56+ messages in thread
From: Luke-Jr @ 2013-12-08 12:37 UTC (permalink / raw)
To: bitcoin-development
On Sunday, December 08, 2013 9:03:38 AM Saïvann Carignan wrote:
> Binaries:
> Sourceforge is not encrypted, actually. Although binaries hosting /
> sharing could be a separate subject discussed later I think.
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.
Luke
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 10:00 ` Drak
@ 2013-12-08 12:39 ` Luke-Jr
2013-12-08 16:51 ` Gregory Maxwell
1 sibling, 0 replies; 56+ messages in thread
From: Luke-Jr @ 2013-12-08 12:39 UTC (permalink / raw)
To: bitcoin-development
On Sunday, December 08, 2013 10:00:35 AM Drak wrote:
> Also it's about time we hosted the Bitcoin Qt software at Github. They have
> a releases feature where you can upload a packaged release (see
> https://github.com/blog/1547-release-your-software). There are also no
> adverts (another privacy leak at the least) and many feel are more
> trustworthy than Sourceforge: it also makes sense to have the downloads
> where the source is developed.
I'm not aware of any rational basis for trusting GitHub more than SourceForge.
At least SourceForge is transparent and releases their source code.
Luke
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 1:17 [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts? Saïvann Carignan
2013-12-08 3:38 ` Odinn Cyberguerrilla
@ 2013-12-08 16:08 ` Wladimir
1 sibling, 0 replies; 56+ messages in thread
From: Wladimir @ 2013-12-08 16:08 UTC (permalink / raw)
To: Saïvann Carignan; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 343 bytes --]
On Sun, Dec 8, 2013 at 2:17 AM, Saïvann Carignan <saivann@gmail•com> wrote:
> I would like to know what are your thoughts on moving bitcoin.org on a
> dedicated server with a SSL certificate?
>
Good idea.
If anything, these days, not using https is sort of a smell for sites that
security is not being taken seriously.
Wladimir
[-- Attachment #2: Type: text/html, Size: 738 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 10:00 ` Drak
2013-12-08 12:39 ` Luke-Jr
@ 2013-12-08 16:51 ` Gregory Maxwell
1 sibling, 0 replies; 56+ messages in thread
From: Gregory Maxwell @ 2013-12-08 16:51 UTC (permalink / raw)
To: Drak; +Cc: Bitcoin Dev
On Sun, Dec 8, 2013 at 2:00 AM, Drak <drak@zikula•org> wrote:
> There is really no excuse for not using an SSL certificate. Without one it
> would be trivial for an attacker to change the contents of the page via
> MITM.
Having control of the site gives you a cert regardless, as several CAs
will issue a cert to anyone who can make a http page appear at a
specific URL at the domain when requested via the CA over http.
It really is darn near pretextual security in this kind case— only
protecting you against attacks near the client, not the server— but as
Wladimir says, it's expected and I don't see how it would be a harm.
The revocation argument is somewhat interesting, especially since any
such site should use HSTS or otherwise a downgrade attack is trivial.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 12:37 ` Luke-Jr
@ 2013-12-08 19:16 ` Drak
2013-12-08 19:25 ` Gregory Maxwell
0 siblings, 1 reply; 56+ messages in thread
From: Drak @ 2013-12-08 19:16 UTC (permalink / raw)
To: Luke-Jr; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2137 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 2968 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 19:16 ` Drak
@ 2013-12-08 19:25 ` Gregory Maxwell
2013-12-08 20:28 ` Mike Hearn
` (2 more replies)
0 siblings, 3 replies; 56+ messages in thread
From: Gregory Maxwell @ 2013-12-08 19:25 UTC (permalink / raw)
To: Drak; +Cc: Bitcoin Dev
On Sun, Dec 8, 2013 at 11:16 AM, Drak <drak@zikula•org> wrote:
> BGP redirection is a reality and can be exploited without much
You're managing to argue against SSL. Because it actually provides
basically protection against an attacker who can actively intercept
traffic to the server. Against that threat model SSL is clearly— based
on your comments— providing a false sense of security.
We _do_ have protection that protect against that— the pgp signature,
but they are far from a solution since people do not check that.
(I'm not suggesting we shouldn't have it, I'm suggesting you stop
arguing SSL provides protection it doesn't before you manage to change
my mind!)
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 19:25 ` Gregory Maxwell
@ 2013-12-08 20:28 ` Mike Hearn
2013-12-08 20:40 ` Gregory Maxwell
` (2 more replies)
2013-12-08 20:40 ` Drak
2013-12-12 20:51 ` Adam Back
2 siblings, 3 replies; 56+ messages in thread
From: Mike Hearn @ 2013-12-08 20:28 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2497 bytes --]
Issues that would need to be resolved:
1) Who pays for it? Most obvious answer: Foundation. However there's
currently a fairly clear line between the foundation website and the
bitcoin.org website. I personally am fine with the bitcoin foundation
funding the website, it's a lot closer to the bitcoin community than
github. But some people might care. So next step would be to contact the
Foundation board and see if they're willing to fund it.
2) Anti-DoS? I assume github handles this at the moment, though I doubt
there's anything to be gained from DoSing the informational website
3) Where does the server go? Ideally, a hosting provider that accepts
Bitcoin of course!
4) Who admins it?
5) Who controls DNS for it?
Right now I think Sirius still owns DNS for bitcoin.org which is nonsense.
He needs to pass it on to someone who is actually still involved with the
project. Again, the most obvious neutral candidate would be the Foundation.
So I think it's a good idea but there's a fair amount of work here. The
primary upside I see is that it opens the potential for adding
interactive/server-side code in future if we decide that would be useful.
On Sun, Dec 8, 2013 at 8:25 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> On Sun, Dec 8, 2013 at 11:16 AM, Drak <drak@zikula•org> wrote:
> > BGP redirection is a reality and can be exploited without much
>
> You're managing to argue against SSL. Because it actually provides
> basically protection against an attacker who can actively intercept
> traffic to the server. Against that threat model SSL is clearly— based
> on your comments— providing a false sense of security.
>
> We _do_ have protection that protect against that— the pgp signature,
> but they are far from a solution since people do not check that.
>
> (I'm not suggesting we shouldn't have it, I'm suggesting you stop
> arguing SSL provides protection it doesn't before you manage to change
> my mind!)
>
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 3498 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 19:25 ` Gregory Maxwell
2013-12-08 20:28 ` Mike Hearn
@ 2013-12-08 20:40 ` Drak
2013-12-08 20:50 ` Gregory Maxwell
2013-12-12 20:51 ` Adam Back
2 siblings, 1 reply; 56+ messages in thread
From: Drak @ 2013-12-08 20:40 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 915 bytes --]
On 8 December 2013 19:25, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> On Sun, Dec 8, 2013 at 11:16 AM, Drak <drak@zikula•org> wrote:
> > BGP redirection is a reality and can be exploited without much
>
> You're managing to argue against SSL. Because it actually provides
> basically protection against an attacker who can actively intercept
> traffic to the server. Against that threat model SSL is clearly— based
> on your comments— providing a false sense of security.
Let me clarify. SSL renders BGP redirection useless because the browser
holds the signatures of CA's it trusts: an attacker cannot spoof a
certificate because it needs to be signed by a trusted CA: that's the point
of SSL, it encrypts and proves identity, the latter part is what thwarts
MITM. If there was an MITM the browser screams pretty loudly about it with
a big threat warning interstitial.
Regards,
Drak
[-- Attachment #2: Type: text/html, Size: 1360 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 20:28 ` Mike Hearn
@ 2013-12-08 20:40 ` Gregory Maxwell
2013-12-08 20:51 ` Drak
2013-12-08 21:16 ` Saïvann Carignan
2013-12-08 21:46 ` Mark Friedenbach
2 siblings, 1 reply; 56+ messages in thread
From: Gregory Maxwell @ 2013-12-08 20:40 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
On Sun, Dec 8, 2013 at 12:28 PM, Mike Hearn <mike@plan99•net> wrote:
> Right now I think Sirius still owns DNS for bitcoin.org which is nonsense.
> He needs to pass it on to someone who is actually still involved with the
> project. Again, the most obvious neutral candidate would be the Foundation.
I am opposed to Bitcoin Foundation having control of Bitcoin.org, and
I think it would be foolish of the foundation to accept it were it
offered.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 20:40 ` Drak
@ 2013-12-08 20:50 ` Gregory Maxwell
2013-12-08 21:07 ` Drak
0 siblings, 1 reply; 56+ messages in thread
From: Gregory Maxwell @ 2013-12-08 20:50 UTC (permalink / raw)
To: Drak; +Cc: Bitcoin Dev
On Sun, Dec 8, 2013 at 12:40 PM, Drak <drak@zikula•org> wrote:
> Let me clarify. SSL renders BGP redirection useless because the browser
> holds the signatures of CA's it trusts: an attacker cannot spoof a
> certificate because it needs to be signed by a trusted CA: that's the point
> of SSL, it encrypts and proves identity, the latter part is what thwarts
> MITM. If there was an MITM the browser screams pretty loudly about it with a
> big threat warning interstitial.
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.
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—
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.
I'm sorry for the tangent here— I think this sub-discussion is really
unrelated to having Bitcoin.org behind SSL— 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.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 20:40 ` Gregory Maxwell
@ 2013-12-08 20:51 ` Drak
2013-12-08 21:01 ` Luke-Jr
2013-12-08 21:09 ` Gregory Maxwell
0 siblings, 2 replies; 56+ messages in thread
From: Drak @ 2013-12-08 20:51 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
On 8 December 2013 20:40, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> On Sun, Dec 8, 2013 at 12:28 PM, Mike Hearn <mike@plan99•net> wrote:
> > Right now I think Sirius still owns DNS for bitcoin.org which is
> nonsense.
> > He needs to pass it on to someone who is actually still involved with the
> > project. Again, the most obvious neutral candidate would be the
> Foundation.
>
> I am opposed to Bitcoin Foundation having control of Bitcoin.org, and
> I think it would be foolish of the foundation to accept it were it
> offered.
>
What do you suggest though? We will need to trust someone (even in a group
each person can act autonomously).
The only thing I can suggest would be to hand the keys to the bitcoin
project lead.
Otherwise, who has admin rights to the code projects
(github/sourceforge/this mailing list)? Those people have proven they can
be trusted so far.
Drak
[-- Attachment #2: Type: text/html, Size: 1523 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 20:51 ` Drak
@ 2013-12-08 21:01 ` Luke-Jr
2013-12-08 21:11 ` Drak
2013-12-08 21:09 ` Gregory Maxwell
1 sibling, 1 reply; 56+ messages in thread
From: Luke-Jr @ 2013-12-08 21:01 UTC (permalink / raw)
To: bitcoin-development
On Sunday, December 08, 2013 8:51:07 PM Drak wrote:
> Otherwise, who has admin rights to the code projects
> (github/sourceforge/this mailing list)? Those people have proven they can
> be trusted so far.
Can someone explain how Sirius has proven the least bit untrustworthy?
Luke
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 20:50 ` Gregory Maxwell
@ 2013-12-08 21:07 ` Drak
2013-12-08 21:14 ` Gregory Maxwell
0 siblings, 1 reply; 56+ messages in thread
From: Drak @ 2013-12-08 21:07 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3152 bytes --]
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—
> 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— I think this sub-discussion is really
> unrelated to having Bitcoin.org behind SSL— 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
[-- Attachment #2: Type: text/html, Size: 4053 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 20:51 ` Drak
2013-12-08 21:01 ` Luke-Jr
@ 2013-12-08 21:09 ` Gregory Maxwell
1 sibling, 0 replies; 56+ messages in thread
From: Gregory Maxwell @ 2013-12-08 21:09 UTC (permalink / raw)
To: Drak; +Cc: Bitcoin Dev
On Sun, Dec 8, 2013 at 12:51 PM, Drak <drak@zikula•org> wrote:
> What do you suggest though? We will need to trust someone (even in a group
> each person can act autonomously).
> The only thing I can suggest would be to hand the keys to the bitcoin
> project lead.
>
> Otherwise, who has admin rights to the code projects
> (github/sourceforge/this mailing list)? Those people have proven they can be
> trusted so far.
My concern isn't a matter of trustworthyness, it's a matter of too
many eggs in one basket (especially a basket with potentially poor
jurisdictional locality). The current control of the domain has
proven reasonably trustworthy, and if there is a concern for funding
our own server stuff that can be easily handled (e.g. if need be, I'd
pay for it myself, without being in control of it).
Also, in terms of effective lobbying/advocacy I worry that the
foundation would be unable to do an effective job if its saddled with
the belief that its in control of Bitcoin ("Why don't you just make
every transaction {...}": the answer is because its a decentralized
system and no one can unilaterally change it in ways its users would
hate, but it becomes complicated. It's crisper when its clear that
diverse and independant parties are in control of the popular
infrastructure).
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 21:01 ` Luke-Jr
@ 2013-12-08 21:11 ` Drak
2013-12-08 23:51 ` theymos
0 siblings, 1 reply; 56+ messages in thread
From: Drak @ 2013-12-08 21:11 UTC (permalink / raw)
To: Luke-Jr; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 739 bytes --]
On 8 December 2013 21:01, Luke-Jr <luke@dashjr•org> wrote:
> On Sunday, December 08, 2013 8:51:07 PM Drak wrote:
> > Otherwise, who has admin rights to the code projects
> > (github/sourceforge/this mailing list)? Those people have proven they can
> > be trusted so far.
>
> Can someone explain how Sirius has proven the least bit untrustworthy?
It's not just about trust, there is the robustness factor: what if he
becomes sick, unavailable, hit by a bus? Others need the ability to pickup
and run with it. The control over the domain (including ability to renew
registration, alter nameservers) needs to be with more than one person.
That's why I suggest using the same people who have control over the
software project at sf,github.
[-- Attachment #2: Type: text/html, Size: 1151 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 21:07 ` Drak
@ 2013-12-08 21:14 ` Gregory Maxwell
2013-12-08 22:27 ` Robert McKay
0 siblings, 1 reply; 56+ messages in thread
From: Gregory Maxwell @ 2013-12-08 21:14 UTC (permalink / raw)
To: Drak; +Cc: Bitcoin Dev
On Sun, Dec 8, 2013 at 1:07 PM, Drak <drak@zikula•org> wrote:
> 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
Godaddy and many other CA's are verified from nothing other than a
http fetch, no email involved.
As I said, I'm willing to demonstrate if you have a domain.
> You cannot MITM SSL connections
You can, once you've obtained a certificate.
> Anyway, I take your points, but this is an area I am quite passionate about
> so it's important for me to be clear.
As I warned before, you're making my reconsider my position about the
downloads being SSL. If people are so convinced that SSL provides
protection it does not that even with an explanation and and an offer
to demonstrate then perhaps providing SSL will reduce people's
security.
... the _only_ reason I don't yet hold that position now is that I
know objectively that almost no one tests the signatures.
On Sun, Dec 8, 2013 at 1:11 PM, Drak <drak@zikula•org> wrote:
> It's not just about trust, there is the robustness factor: what if he
> becomes sick, unavailable, hit by a bus? Others need the ability to pickup
> and run with it. The control over the domain (including ability to renew
> registration, alter nameservers) needs to be with more than one person.
> That's why I suggest using the same people who have control over the
> software project at sf,github.
My understanding is that the domain is already controlled by more than
one person. You're not the first person to think of these things. :)
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 20:28 ` Mike Hearn
2013-12-08 20:40 ` Gregory Maxwell
@ 2013-12-08 21:16 ` Saïvann Carignan
2013-12-08 21:58 ` Roy Badami
` (3 more replies)
2013-12-08 21:46 ` Mark Friedenbach
2 siblings, 4 replies; 56+ messages in thread
From: Saïvann Carignan @ 2013-12-08 21:16 UTC (permalink / raw)
To: bitcoin-development
> Issues that would need to be resolved:
>
> 1) Who pays for it? Most obvious answer: Foundation. However there's
> currently a fairly clear line between the foundation website and the
> bitcoin.org <http://bitcoin.org> website. I personally am fine with the
> bitcoin foundation funding the website, it's a lot closer to the bitcoin
> community than github. But some people might care. So next step would be
> to contact the Foundation board and see if they're willing to fund it.
Actually I might find way to fund it. But I needed to have ACK &
comments from developers before anything.
> 2) Anti-DoS? I assume github handles this at the moment, though I doubt
> there's anything to be gained from DoSing the informational website
That is a fair question, we will need anti-DDoS. Unless something better
(and affordable) can be recommended, this would yet put another Bitcoin
website under CloudFlare.
> 4) Who admins it?
Obviously, I thought it would be important that the server is owned by
someone who can be trusted, with ssh access for all core developers.
> 5) Who controls DNS for it?
I'm not sure we'll get any change on this level. I have no idea if the
domain is in good hands, except for the fact that nothing bad happened
thus far. If anything, moving it to core developers (as intended when
the domain was registered) would make more sense IMO. But again, is it
possible, I don't know.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 20:28 ` Mike Hearn
2013-12-08 20:40 ` Gregory Maxwell
2013-12-08 21:16 ` Saïvann Carignan
@ 2013-12-08 21:46 ` Mark Friedenbach
2 siblings, 0 replies; 56+ messages in thread
From: Mark Friedenbach @ 2013-12-08 21:46 UTC (permalink / raw)
To: Mike Hearn; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 3327 bytes --]
I too would be against the foundation taking control of hosting or the
domain. I have no reason at this time not to trust them, by checks and
balances are a good thing.
On Dec 8, 2013 12:29 PM, "Mike Hearn" <mike@plan99•net> wrote:
> Issues that would need to be resolved:
>
> 1) Who pays for it? Most obvious answer: Foundation. However there's
> currently a fairly clear line between the foundation website and the
> bitcoin.org website. I personally am fine with the bitcoin foundation
> funding the website, it's a lot closer to the bitcoin community than
> github. But some people might care. So next step would be to contact the
> Foundation board and see if they're willing to fund it.
>
> 2) Anti-DoS? I assume github handles this at the moment, though I doubt
> there's anything to be gained from DoSing the informational website
>
> 3) Where does the server go? Ideally, a hosting provider that accepts
> Bitcoin of course!
>
> 4) Who admins it?
>
> 5) Who controls DNS for it?
>
> Right now I think Sirius still owns DNS for bitcoin.org which is
> nonsense. He needs to pass it on to someone who is actually still involved
> with the project. Again, the most obvious neutral candidate would be the
> Foundation.
>
> So I think it's a good idea but there's a fair amount of work here. The
> primary upside I see is that it opens the potential for adding
> interactive/server-side code in future if we decide that would be useful.
>
>
>
> On Sun, Dec 8, 2013 at 8:25 PM, Gregory Maxwell <gmaxwell@gmail•com>wrote:
>
>> On Sun, Dec 8, 2013 at 11:16 AM, Drak <drak@zikula•org> wrote:
>> > BGP redirection is a reality and can be exploited without much
>>
>> You're managing to argue against SSL. Because it actually provides
>> basically protection against an attacker who can actively intercept
>> traffic to the server. Against that threat model SSL is clearly— based
>> on your comments— providing a false sense of security.
>>
>> We _do_ have protection that protect against that— the pgp signature,
>> but they are far from a solution since people do not check that.
>>
>> (I'm not suggesting we shouldn't have it, I'm suggesting you stop
>> arguing SSL provides protection it doesn't before you manage to change
>> my mind!)
>>
>>
>> ------------------------------------------------------------------------------
>> Sponsored by Intel(R) XDK
>> Develop, test and display web and hybrid apps with a single code base.
>> Download it for free now!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 4805 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 21:16 ` Saïvann Carignan
@ 2013-12-08 21:58 ` Roy Badami
2013-12-08 23:03 ` Mike Hearn
2013-12-08 22:44 ` Gavin Andresen
` (2 subsequent siblings)
3 siblings, 1 reply; 56+ messages in thread
From: Roy Badami @ 2013-12-08 21:58 UTC (permalink / raw)
To: Sa?vann Carignan; +Cc: bitcoin-development
> > 5) Who controls DNS for it?
>
> I'm not sure we'll get any change on this level. I have no idea if the
> domain is in good hands, except for the fact that nothing bad happened
> thus far. If anything, moving it to core developers (as intended when
> the domain was registered) would make more sense IMO. But again, is it
> possible, I don't know.
That's an interesting question. The bitcoin.org domain is hiding
behind a WhoisGuard anonymous registration. Why are we not allowed to
know who this domain belongs to? Why are we being asked to trust some
unidentified party?
roy
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 21:14 ` Gregory Maxwell
@ 2013-12-08 22:27 ` Robert McKay
0 siblings, 0 replies; 56+ messages in thread
From: Robert McKay @ 2013-12-08 22:27 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
On Sun, 8 Dec 2013 13:14:44 -0800, Gregory Maxwell wrote:
> On Sun, Dec 8, 2013 at 1:07 PM, Drak <drak@zikula•org> wrote:
>> 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
>
> Godaddy and many other CA's are verified from nothing other than a
> http fetch, no email involved.
It's just as easy to steal emails via a BGP or DNS redirect anyway..
you could even take over the actual domain at the registry level by
stealing a password reset via BGP or DNS redirect and actually many
registries will hand over control of a domain by faxing them a forged
driving license in the owner's name anyway so it doesn't even really
need to be a particularly sophisticated attacker. Once you have registry
control of the domain it's easy enough to get an SSL cert too, probably
even an 'extended validation' one.
When Afghanistan was taken over the entire .af TLD was probably
transferred using a forged fax to ICANN
(http://web.archive.org/web/20041017031020/http://www.iana.org/cctld/af/razeeq-letter-13aug02.pdf)
but I guess that's a little different :p
Rob
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 21:16 ` Saïvann Carignan
2013-12-08 21:58 ` Roy Badami
@ 2013-12-08 22:44 ` Gavin Andresen
2013-12-08 23:48 ` Saïvann Carignan
2013-12-08 23:18 ` Luke-Jr
2013-12-08 23:29 ` Patrick
3 siblings, 1 reply; 56+ messages in thread
From: Gavin Andresen @ 2013-12-08 22:44 UTC (permalink / raw)
To: Saïvann Carignan; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 733 bytes --]
>
> > 4) Who admins it?
>
> Obviously, I thought it would be important that the server is owned by
> someone who can be trusted, with ssh access for all core developers.
>
That is a really bad idea. If there is not a CLEAR answer to "who admins
it", there will be a bunch of "I thought YOU were applying security
patches... no, I thought YOU were..." the first time it gets hacked.
So, the question is: who wants to take responsibility for keeping
bitcoin.org safe and secure?
I am not going to do that, I've got too many other things to worry about.
It is exactly the type of thing the Foundation was setup to do, but if
y'all want to create some other organization to do it, then please make it
happen.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 1275 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 21:58 ` Roy Badami
@ 2013-12-08 23:03 ` Mike Hearn
2013-12-09 5:32 ` Jeff Garzik
0 siblings, 1 reply; 56+ messages in thread
From: Mike Hearn @ 2013-12-08 23:03 UTC (permalink / raw)
To: Roy Badami; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 572 bytes --]
> That's an interesting question. The bitcoin.org domain is hiding
> behind a WhoisGuard anonymous registration. Why are we not allowed to
> know who this domain belongs to? Why are we being asked to trust some
> unidentified party?
It's done that way because it was originally registered by Satoshi. It's
now controlled by Sirius, who doesn't really take part in the project
anymore.
I bring this up because of the recent bitcointalk fiasco. AFAIK the domains
are registered and controlled in the same way. It's likely that the current
registrar isn't very secure.
[-- Attachment #2: Type: text/html, Size: 911 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 21:16 ` Saïvann Carignan
2013-12-08 21:58 ` Roy Badami
2013-12-08 22:44 ` Gavin Andresen
@ 2013-12-08 23:18 ` Luke-Jr
2013-12-08 23:29 ` Patrick
3 siblings, 0 replies; 56+ messages in thread
From: Luke-Jr @ 2013-12-08 23:18 UTC (permalink / raw)
To: bitcoin-development
On Sunday, December 08, 2013 9:16:09 PM Saïvann Carignan wrote:
> > 1) Who pays for it? Most obvious answer: Foundation. However there's
> > currently a fairly clear line between the foundation website and the
> > bitcoin.org <http://bitcoin.org> website. I personally am fine with the
> > bitcoin foundation funding the website, it's a lot closer to the bitcoin
> > community than github. But some people might care. So next step would be
> > to contact the Foundation board and see if they're willing to fund it.
>
> Actually I might find way to fund it. But I needed to have ACK &
> comments from developers before anything.
>
> ...
> > 4) Who admins it?
>
> Obviously, I thought it would be important that the server is owned by
> someone who can be trusted, with ssh access for all core developers.
>
> > 5) Who controls DNS for it?
>
> I'm not sure we'll get any change on this level. I have no idea if the
> domain is in good hands, except for the fact that nothing bad happened
> thus far. If anything, moving it to core developers (as intended when
> the domain was registered) would make more sense IMO. But again, is it
> possible, I don't know.
I don't think "core developers" should be directly in control here any more
than the Foundation should. Developers are good for development, not
necessarily web or server admin tasks. Only those directly involved in the
needed roles should have access IMO.
Luke
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 21:16 ` Saïvann Carignan
` (2 preceding siblings ...)
2013-12-08 23:18 ` Luke-Jr
@ 2013-12-08 23:29 ` Patrick
3 siblings, 0 replies; 56+ messages in thread
From: Patrick @ 2013-12-08 23:29 UTC (permalink / raw)
To: bitcoin-development
Have you considered black lotus dedicated servers?
On 12/08/2013 03:16 PM, Saïvann Carignan wrote:
>> Issues that would need to be resolved:
>>
>> 1) Who pays for it? Most obvious answer: Foundation. However there's
>> currently a fairly clear line between the foundation website and the
>> bitcoin.org <http://bitcoin.org> website. I personally am fine with the
>> bitcoin foundation funding the website, it's a lot closer to the bitcoin
>> community than github. But some people might care. So next step would be
>> to contact the Foundation board and see if they're willing to fund it.
> Actually I might find way to fund it. But I needed to have ACK &
> comments from developers before anything.
>
>> 2) Anti-DoS? I assume github handles this at the moment, though I doubt
>> there's anything to be gained from DoSing the informational website
> That is a fair question, we will need anti-DDoS. Unless something better
> (and affordable) can be recommended, this would yet put another Bitcoin
> website under CloudFlare.
>
>> 4) Who admins it?
> Obviously, I thought it would be important that the server is owned by
> someone who can be trusted, with ssh access for all core developers.
>
>> 5) Who controls DNS for it?
> I'm not sure we'll get any change on this level. I have no idea if the
> domain is in good hands, except for the fact that nothing bad happened
> thus far. If anything, moving it to core developers (as intended when
> the domain was registered) would make more sense IMO. But again, is it
> possible, I don't know.
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 22:44 ` Gavin Andresen
@ 2013-12-08 23:48 ` Saïvann Carignan
0 siblings, 0 replies; 56+ messages in thread
From: Saïvann Carignan @ 2013-12-08 23:48 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev
> > 4) Who admins it?
>
> Obviously, I thought it would be important that the server is owned by
> someone who can be trusted, with ssh access for all core developers.
>
>
> That is a really bad idea. If there is not a CLEAR answer to "who
> admins it", there will be a bunch of "I thought YOU were applying
> security patches... no, I thought YOU were..." the first time it gets
> hacked.
>
> So, the question is: who wants to take responsibility for keeping
> bitcoin.org <http://bitcoin.org> safe and secure?
>
> I am not going to do that, I've got too many other things to worry
> about. It is exactly the type of thing the Foundation was setup to do,
> but if y'all want to create some other organization to do it, then
> please make it happen.
>
> --
> --
> Gavin Andresen
>
I fully agree that someone *must* be assigned to the task, otherwise
it's better keeping current hosting.
Perhaps that was implicit, but I can take this responsibility so long as
I can be replaced if required for any reason. On this regard, I agree
that the Foundation funding / owning / securing the server
infrastructure is a much better long term strategy.
This said, I also agree that it is a better idea to keep the domain and
website content independently owned and managed, for the reasons stated
by Gregory Maxwell.
If there isn't a good consensus on one of the two options I suggested, I
vote we don't lose more time on this question and keep focus with bigger
priorities.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 21:11 ` Drak
@ 2013-12-08 23:51 ` theymos
2013-12-09 0:06 ` Taylor Gerring
` (3 more replies)
0 siblings, 4 replies; 56+ messages in thread
From: theymos @ 2013-12-08 23:51 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 824 bytes --]
On Sun, Dec 8, 2013, at 03:11 PM, Drak wrote:
It's not just about trust, there is the robustness factor: what if he
becomes sick, unavailable, hit by a bus? Others need the ability to
pickup and run with it. The control over the domain (including ability
to renew registration, alter nameservers) needs to be with more than
one person. That's why I suggest using the same people who have control
over the software project at sf,github
The bitcoin.org domain is controlled by me, Sirius, and an anonymous
person. Control will not be lost if Sirius becomes unavailable.
SSL is probably a good idea, and it's probably also a good idea to
separate bitcoin.org from Github. I don't know that I trust Github. I'm
sure that you can find a sponsor for a dedicated server. Let us know if
DNS changes to bitcoin.org are required.
[-- Attachment #2: Type: text/html, Size: 1121 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 23:51 ` theymos
@ 2013-12-09 0:06 ` Taylor Gerring
2013-12-09 6:29 ` Jeremy Spilman
` (2 subsequent siblings)
3 siblings, 0 replies; 56+ messages in thread
From: Taylor Gerring @ 2013-12-09 0:06 UTC (permalink / raw)
To: theymos; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 242 bytes --]
Maybe bitcointalk.org would like to donate a few BTC from the 6,000 BTC "new forum" fund to sponsor hosting?
On Dec 8, 2013, at 5:51 PM, theymos <theymos@mm•st> wrote:
> I'm sure that you can find a sponsor for a dedicated server.
[-- Attachment #2: Type: text/html, Size: 1104 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 23:03 ` Mike Hearn
@ 2013-12-09 5:32 ` Jeff Garzik
0 siblings, 0 replies; 56+ messages in thread
From: Jeff Garzik @ 2013-12-09 5:32 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
On Sun, Dec 8, 2013 at 8:03 PM, Mike Hearn <mike@plan99•net> wrote:
> I bring this up because of the recent bitcointalk fiasco. AFAIK the domains
> are registered and controlled in the same way. It's likely that the current
> registrar isn't very secure.
I registered bitcointalk.org originally, then passed along control.
It is likely that the two domains are /not/ registered and controlled
in the same way.
The handling of bitcointalk.org was quite disappointing. Even after
"control" passed from me to Sirius, he did not bother to change the
registrar credentials for months afterward, despite repeated urging.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 23:51 ` theymos
2013-12-09 0:06 ` Taylor Gerring
@ 2013-12-09 6:29 ` Jeremy Spilman
2013-12-09 10:54 ` Roy Badami
2013-12-10 9:18 ` Odinn Cyberguerrilla
3 siblings, 0 replies; 56+ messages in thread
From: Jeremy Spilman @ 2013-12-09 6:29 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]
I can provide the server hardware and colocation (space, power, and
bandwidth) if dedicated 50Mbit in 55 S. Market, San Jose, CA data center
is acceptable.
If it needs more bandwidth than that, in a few months I hope to be getting
space in LA with 1Gbit, but I can't commit to that now.
> On Sun, Dec 8, 2013, at 03:11 PM, Drak wrote:
>> It's not just about trust, there is the robustness factor: what if he
>> becomes sick, unavailable, hit by a bus? Others need the ability to
>> >>pickup and run with it. The control over the domain (including
>> ability to renew registration, alter nameservers) needs to be with more
>> than >>one person. That's why I suggest using the same people who have
>> control over the software project at sf,github
>The bitcoin.org domain is controlled by me, Sirius, and an anonymous
> person. Control will not be lost if Sirius becomes unavailable.
>SSL is probably a good idea, and it's probably also a good idea to
> separate bitcoin.org from Github. I don't know that I trust Github. I'm
> sure that you can >find a sponsor for a dedicated server. Let us know if
> DNS changes to bitcoin.org are required.
[-- Attachment #2.1: Type: text/html, Size: 1672 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 23:51 ` theymos
2013-12-09 0:06 ` Taylor Gerring
2013-12-09 6:29 ` Jeremy Spilman
@ 2013-12-09 10:54 ` Roy Badami
2013-12-10 9:18 ` Odinn Cyberguerrilla
3 siblings, 0 replies; 56+ messages in thread
From: Roy Badami @ 2013-12-09 10:54 UTC (permalink / raw)
To: theymos; +Cc: bitcoin-development
> The bitcoin.org domain is controlled by me, Sirius, and an anonymous
> person. Control will not be lost if Sirius becomes unavailable.
I know this will be a controversial viewpoint in some quarters, but
I'm not a fan of anonymity, or of pseudonyms. As far as I know
(please correct me if I'm wrong) all the core devs go by their real
names with the exception of Satoshi (and I would hope he no longer has
commit access? - only because I would hope that no-one has
pseudonymous commit access these days). I don't see why this should
be different for the domain, the DNS and the rest of the
infrastructure...
Although that's separate from the question of who the registrant of
the domain should be (the registrant being the closest thing a domain
has to a recorded legal owner). Who currently purports to be the
current legal owner of the domain?
IMHO the registrant should obviously be real and not WhoisGuard -
anonymous stuff like this always looks shady. And surely the Bitcoin
Foundation is the obvious candidate to own the domain (just like
kernel.org is owned by the Linux Foundation). But this may all be
moot unless the current legal owners are willing to assign the
domain...
roy
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 23:51 ` theymos
` (2 preceding siblings ...)
2013-12-09 10:54 ` Roy Badami
@ 2013-12-10 9:18 ` Odinn Cyberguerrilla
3 siblings, 0 replies; 56+ messages in thread
From: Odinn Cyberguerrilla @ 2013-12-10 9:18 UTC (permalink / raw)
To: theymos; +Cc: bitcoin-development
I've been lurking on this convo since it began, but I wanted to say
thanks, theymos
cheers to you all and yay for decentralization, wherever it leads.
-odinn
muh latest: http://github.com/ABISprotocol/ABIS
> On Sun, Dec 8, 2013, at 03:11 PM, Drak wrote:
>
> It's not just about trust, there is the robustness factor: what if he
> becomes sick, unavailable, hit by a bus? Others need the ability to
> pickup and run with it. The control over the domain (including ability
> to renew registration, alter nameservers) needs to be with more than
> one person. That's why I suggest using the same people who have control
> over the software project at sf,github
>
>
> The bitcoin.org domain is controlled by me, Sirius, and an anonymous
> person. Control will not be lost if Sirius becomes unavailable.
>
> SSL is probably a good idea, and it's probably also a good idea to
> separate bitcoin.org from Github. I don't know that I trust Github. I'm
> sure that you can find a sponsor for a dedicated server. Let us know if
> DNS changes to bitcoin.org are required.
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-08 19:25 ` Gregory Maxwell
2013-12-08 20:28 ` Mike Hearn
2013-12-08 20:40 ` Drak
@ 2013-12-12 20:51 ` Adam Back
2013-12-31 13:39 ` Drak
2 siblings, 1 reply; 56+ messages in thread
From: Adam Back @ 2013-12-12 20:51 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
I think the one thing that SSL does provide is some protection against ARP
or DNS poisoning to trick the user into downloading from a different site.
The PGP WoT surrounding bitcoin or OS related ISOs be weak - I am not sure
if I could even check it directly myself despite spending a few hours
tracking down keys and checking fingerprints of biz cards of core devs I met
in person, then that is a relevant point.
Adam
On Sun, Dec 08, 2013 at 11:25:24AM -0800, Gregory Maxwell wrote:
>On Sun, Dec 8, 2013 at 11:16 AM, Drak <drak@zikula•org> wrote:
>> BGP redirection is a reality and can be exploited without much
>
>You're managing to argue against SSL. Because it actually provides
>basically protection against an attacker who can actively intercept
>traffic to the server. Against that threat model SSL is clearly— based
>on your comments— providing a false sense of security.
>
>We _do_ have protection that protect against that— the pgp signature,
>but they are far from a solution since people do not check that.
>
>(I'm not suggesting we shouldn't have it, I'm suggesting you stop
>arguing SSL provides protection it doesn't before you manage to change
>my mind!)
>
>------------------------------------------------------------------------------
>Sponsored by Intel(R) XDK
>Develop, test and display web and hybrid apps with a single code base.
>Download it for free now!
>http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists•sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-12 20:51 ` Adam Back
@ 2013-12-31 13:39 ` Drak
2013-12-31 13:48 ` Gregory Maxwell
0 siblings, 1 reply; 56+ messages in thread
From: Drak @ 2013-12-31 13:39 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]
Has anyone seen the talk at 30c3 on the current NSA capabilities?
https://www.youtube.com/watch?v=b0w36GAyZIA
Specifically they are able to "beat the speed of light" between you and a
website such that if you communicate with Bob, they can sent competing
packets that will arrive before Bob's packets. They have realtime deep
packet insertion able to inject arbitrary data into an TCP streams and can
change file downloads **on the fly**. This can be done remotely.
Sourceforge do not have https downloads, so this is yet another reason to
move downloads to somewhere that does - like github.
The NSA has the ability, right now to change every download of bitcoin-qt,
on the fly and the only cure is encryption.
Revealed as part of the presentation is the fact that if the NSA has access
to these capabilities, then so do others and in fact one of the things
revealed yesterday was independently discovered already and published.
Same goes for the bitcoin.org site - why are we dragging our feet on
installing an SSL certificate and redirecting all http to https? While no
solution is perfect, it's a lot better than zero defense.
You can see the irony of disseminating the bitcoin crypto-currency client
in the clear.
For anyone who has not seen the video. You will be shocked by what is
actually in the wild being used today. It goes way beyond anything
imaginable even in science fiction.
https://www.youtube.com/watch?v=b0w36GAyZIA
Drak
[-- Attachment #2: Type: text/html, Size: 1901 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-31 13:39 ` Drak
@ 2013-12-31 13:48 ` Gregory Maxwell
2013-12-31 13:59 ` Mike Hearn
` (2 more replies)
0 siblings, 3 replies; 56+ messages in thread
From: Gregory Maxwell @ 2013-12-31 13:48 UTC (permalink / raw)
To: Drak; +Cc: Bitcoin Dev
On Tue, Dec 31, 2013 at 5:39 AM, Drak <drak@zikula•org> wrote:
> The NSA has the ability, right now to change every download of bitcoin-qt,
> on the fly and the only cure is encryption.
Please cut it out with the snake oil pedaling. This is really over the
top. You're invoking the NSA as the threat here? Okay. The NSA can
trivially compromise an HTTPS download site: even ignoring the CA
insecurity, and government run CAs certificate authorities issue CA
certs to random governments and corporations for dataloss prevention
purposes. Not to mention unparalleled access to exploits.
The downloads are protected by something far stronger than SSL
already, which might even have a chance against the NSA. Actual
signatures of the downloads with offline keys.
I'm all pro-SSL and all that, but you are— piece by piece— really
convincing me that it produces an entirely false sense of security
which is entirely unjustified.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-31 13:48 ` Gregory Maxwell
@ 2013-12-31 13:59 ` Mike Hearn
2013-12-31 14:18 ` Gregory Maxwell
2014-01-02 19:49 ` Jorge Timón
2013-12-31 14:05 ` Benjamin Cordes
2014-01-03 5:45 ` Troy Benjegerdes
2 siblings, 2 replies; 56+ messages in thread
From: Mike Hearn @ 2013-12-31 13:59 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2965 bytes --]
Given that hardly anyone checks the signatures, it's fair to say downloads
aren't protected by anything at the moment. SSL for downloads can only
raise the bar, never lower it, and if the NSA want to kick off the process
of revoking some of the big CA's then I'm game (assuming anyone detects it
of course) :)
Anyway, nobody is dragging feet, the problem is right now we get what is
effectively a huge free subsidy from github and SourceForge for site
hosting. The cost is no SSL. So getting SSL would require that "we" pay for
it ourselves, but the primary method we have for funding public
goods/infrastructure (the Foundation) which is the subject of various
conspiracy theories. Jeremy has made a generous offer further up the
thread, the issue being I guess none of us know how much traffic we
actually get :( I remember suggesting that we whack Google Analytics or
some other statistics package on when the new website design was done and
that was rejected for similar reasons ("organisations are bad").
So we are in a position where we get a subsidy of large but unknown size
from various existing US corporations, but moving to different ones is
controversial, hence no progress :)
On Tue, Dec 31, 2013 at 1:48 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> On Tue, Dec 31, 2013 at 5:39 AM, Drak <drak@zikula•org> wrote:
> > The NSA has the ability, right now to change every download of
> bitcoin-qt,
> > on the fly and the only cure is encryption.
>
> Please cut it out with the snake oil pedaling. This is really over the
> top. You're invoking the NSA as the threat here? Okay. The NSA can
> trivially compromise an HTTPS download site: even ignoring the CA
> insecurity, and government run CAs certificate authorities issue CA
> certs to random governments and corporations for dataloss prevention
> purposes. Not to mention unparalleled access to exploits.
>
> The downloads are protected by something far stronger than SSL
> already, which might even have a chance against the NSA. Actual
> signatures of the downloads with offline keys.
>
> I'm all pro-SSL and all that, but you are— piece by piece— really
> convincing me that it produces an entirely false sense of security
> which is entirely unjustified.
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 3801 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-31 13:48 ` Gregory Maxwell
2013-12-31 13:59 ` Mike Hearn
@ 2013-12-31 14:05 ` Benjamin Cordes
2014-01-03 5:45 ` Troy Benjegerdes
2 siblings, 0 replies; 56+ messages in thread
From: Benjamin Cordes @ 2013-12-31 14:05 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2301 bytes --]
Interesting. I think the original BitDNS discussion was more interesting
that what currently is happening with namecoin, see
https://bitcointalk.org/index.php?topic=1790.0
Satoshi said there: "1) IP records don't need to be in the chain, just do
registrar function not DNS. And CA problem solved, neat."
Besides, ICANN is currently selling out the global public namespace - not
that anybody really cares about such measly topics as the ownership of
global namespaces. And so some guy on the Cayman Islands is now the largest
holder of TLD's.
On Tue, Dec 31, 2013 at 2:48 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> On Tue, Dec 31, 2013 at 5:39 AM, Drak <drak@zikula•org> wrote:
> > The NSA has the ability, right now to change every download of
> bitcoin-qt,
> > on the fly and the only cure is encryption.
>
> Please cut it out with the snake oil pedaling. This is really over the
> top. You're invoking the NSA as the threat here? Okay. The NSA can
> trivially compromise an HTTPS download site: even ignoring the CA
> insecurity, and government run CAs certificate authorities issue CA
> certs to random governments and corporations for dataloss prevention
> purposes. Not to mention unparalleled access to exploits.
>
> The downloads are protected by something far stronger than SSL
> already, which might even have a chance against the NSA. Actual
> signatures of the downloads with offline keys.
>
> I'm all pro-SSL and all that, but you are— piece by piece— really
> convincing me that it produces an entirely false sense of security
> which is entirely unjustified.
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 3111 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-31 13:59 ` Mike Hearn
@ 2013-12-31 14:18 ` Gregory Maxwell
2013-12-31 14:23 ` Mike Hearn
2014-01-02 19:49 ` Jorge Timón
1 sibling, 1 reply; 56+ messages in thread
From: Gregory Maxwell @ 2013-12-31 14:18 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
On Tue, Dec 31, 2013 at 5:59 AM, Mike Hearn <mike@plan99•net> wrote:
> but moving to different ones is
> controversial, hence no progress :)
The site was actually moved onto a dedicated server temporarily and it
melted down under the load. I wouldn't call that no progress.
Perhaps I wasn't clear on the point I was making Drak's threat model
is not improved in the slightest by SSL. It would be improved by
increasing the use of signature checking, e.g. by making it easier.
Flat out misinformation never improves security.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-31 14:18 ` Gregory Maxwell
@ 2013-12-31 14:23 ` Mike Hearn
2013-12-31 21:25 ` Jeremy Spilman
2014-01-01 22:15 ` Mike Hearn
0 siblings, 2 replies; 56+ messages in thread
From: Mike Hearn @ 2013-12-31 14:23 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]
>
> The site was actually moved onto a dedicated server temporarily and it
> melted down under the load. I wouldn't call that no progress.
>
Oh, it did? When was that? I must have missed this excitement :)
Any idea how much load it had?
Perhaps I wasn't clear on the point I was making Drak's threat model
> is not improved in the slightest by SSL. It would be improved by
> increasing the use of signature checking, e.g. by making it easier.
>
Well, that depends. If you watch Applebaums talk he is pushing TLS pretty
hard, and saying that based on the access to the source docs some of their
MITM attacks can't beat TLS. It appears that they have the capability to do
bulk MITM and rewrite of downloads as Drak says but *not* when TLS is
present, that would force more targeted attacks. So to me that implies that
TLS does raise the bar and is worth doing.
However if we can't find a server that won't melt under the load, then
that'd be an issue. We could consider hosting downloads on AppEngine or
something else that can handle both high load and TLS.
[-- Attachment #2: Type: text/html, Size: 1532 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-31 14:23 ` Mike Hearn
@ 2013-12-31 21:25 ` Jeremy Spilman
2013-12-31 21:33 ` Matt Corallo
2014-01-01 15:10 ` Mike Hearn
2014-01-01 22:15 ` Mike Hearn
1 sibling, 2 replies; 56+ messages in thread
From: Jeremy Spilman @ 2013-12-31 21:25 UTC (permalink / raw)
To: Gregory Maxwell, Mike Hearn; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3364 bytes --]
I didn't know about the dedicated server meltdown, it wasn't any of my
infra. Anyway, my previous offer still stands.
One less 'security theater' approach would be if we could provide
forward-validation of updates using the blockchain. It's always going to
be up to the user the first time they install the wallet to verify the
provenance of the binaries/source. From that point forward, we could make
it easier if the wallet could detect updates and prove they were valid.
This could be as simple as hard-coding a public key into the client and
checking a signature on the new binaries. But it could also be more
interesting...
For example, a well known address on the blockchain corresponds to
multi-sig with keys controlled by developers (or whatever key policy the
release team wants to impose). A spend from that address announces a new
release, and includes the expected hash of the file.
You would probably need some way to handle the different release targets.
A more rigorous approach could identify all the various releases in terms
of a BIP32 xpubkey whose branches would correspond to the different
release trains and platform builds. Spends from a node announce the
release and the expected hash.
This provides zero benefit if the wallet software is already compromised,
but I think this would allow trusted automatic update notification, and a
trusted way to deliver the expected hashes. It also might resolve some of
the consternation around when a release is truly "released", if that's
really a problem.
I'm not sure how far along the slope you would want to go; 1) announcing
updates in the UI, 2) providing a button the user could click to verify a
binary matches its expected hash, 3) click to download and verify the
upgrade matches the expected hash, 4) click to upgrade
Formalizing the release process around a set of privkeys (or split shares
of keys) may raise its own set of questions.
For the download itself, I've heard the advocates of announcing
availability on the blockchain leading to a BitTorrent magnet link, but I
also understand objections to adding an entire BitTorrent stack into a
wallet.
On Tue, 31 Dec 2013 06:23:55 -0800, Mike Hearn <mike@plan99•net> wrote:
>> The site was actually moved onto a dedicated server temporarily and it
>> melted down under the load. I wouldn't call that no progress.
>
> Oh, it did? When was that? I must have missed this excitement :)
>Any idea how much load it had?
>
>> Perhaps I wasn't clear on the point I was making Drak's threat model
>> is not improved in the slightest by SSL. It would be improved by
>> increasing the use of signature checking, e.g. by making it easier.
>
> Well, that depends. If you watch Applebaums talk he is pushing TLS
> pretty hard, and saying that based on the access to the source docs some
> of >their MITM attacks can't beat TLS. It appears that they have the
> capability to do bulk MITM and rewrite of downloads as Drak says but
> *not* when >TLS is present, that would force more targeted attacks. So
> to me that implies that TLS does raise the bar and is worth doing.
>
> However if we can't find a server that won't melt under the load, then
> that'd be an issue. We could consider hosting downloads on AppEngine or
> >something else that can handle both high load and TLS.
[-- Attachment #2.1: Type: text/html, Size: 4217 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-31 21:25 ` Jeremy Spilman
@ 2013-12-31 21:33 ` Matt Corallo
2014-01-01 10:02 ` Jeremy Spilman
2014-01-01 15:10 ` Mike Hearn
1 sibling, 1 reply; 56+ messages in thread
From: Matt Corallo @ 2013-12-31 21:33 UTC (permalink / raw)
To: Jeremy Spilman, Gregory Maxwell, Mike Hearn; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 4621 bytes --]
We already have a wonderful system for secure updating - gitian-downloader. We just neither use it not bother making actual gitian releases so anyone can use it to verify signatures of downloads.
Jeremy Spilman <jeremy@taplink•co> wrote:
>I didn't know about the dedicated server meltdown, it wasn't any of my
>
>infra. Anyway, my previous offer still stands.
>
>One less 'security theater' approach would be if we could provide
>forward-validation of updates using the blockchain. It's always going
>to
>be up to the user the first time they install the wallet to verify the
>
>provenance of the binaries/source. From that point forward, we could
>make
>it easier if the wallet could detect updates and prove they were valid.
>
>This could be as simple as hard-coding a public key into the client and
>
>checking a signature on the new binaries. But it could also be more
>interesting...
>
>For example, a well known address on the blockchain corresponds to
>multi-sig with keys controlled by developers (or whatever key policy
>the
>release team wants to impose). A spend from that address announces a
>new
>release, and includes the expected hash of the file.
>
>You would probably need some way to handle the different release
>targets.
>A more rigorous approach could identify all the various releases in
>terms
>of a BIP32 xpubkey whose branches would correspond to the different
>release trains and platform builds. Spends from a node announce the
>release and the expected hash.
>
>This provides zero benefit if the wallet software is already
>compromised,
>but I think this would allow trusted automatic update notification, and
>a
>trusted way to deliver the expected hashes. It also might resolve some
>of
>the consternation around when a release is truly "released", if that's
>
>really a problem.
>
>I'm not sure how far along the slope you would want to go; 1)
>announcing
>updates in the UI, 2) providing a button the user could click to verify
>a
>binary matches its expected hash, 3) click to download and verify the
>upgrade matches the expected hash, 4) click to upgrade
>
>Formalizing the release process around a set of privkeys (or split
>shares
>of keys) may raise its own set of questions.
>
>For the download itself, I've heard the advocates of announcing
>availability on the blockchain leading to a BitTorrent magnet link, but
>I
>also understand objections to adding an entire BitTorrent stack into a
>
>wallet.
>
>On Tue, 31 Dec 2013 06:23:55 -0800, Mike Hearn <mike@plan99•net> wrote:
>
>>> The site was actually moved onto a dedicated server temporarily and
>it
>>> melted down under the load. I wouldn't call that no progress.
>>
>> Oh, it did? When was that? I must have missed this excitement :)
>>Any idea how much load it had?
>>
>>> Perhaps I wasn't clear on the point I was making Drak's threat model
>>> is not improved in the slightest by SSL. It would be improved by
>>> increasing the use of signature checking, e.g. by making it easier.
>>
>> Well, that depends. If you watch Applebaums talk he is pushing TLS
>> pretty hard, and saying that based on the access to the source docs
>some
>> of >their MITM attacks can't beat TLS. It appears that they have the
>
>> capability to do bulk MITM and rewrite of downloads as Drak says but
>
>> *not* when >TLS is present, that would force more targeted attacks.
>So
>> to me that implies that TLS does raise the bar and is worth doing.
>>
>> However if we can't find a server that won't melt under the load,
>then
>> that'd be an issue. We could consider hosting downloads on AppEngine
>or
>> >something else that can handle both high load and TLS.
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>Rapidly troubleshoot problems before they affect your business. Most IT
>
>organizations don't have a clear picture of how application performance
>
>affects their revenue. With AppDynamics, you get 100% visibility into
>your
>Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>AppDynamics Pro!
>http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists•sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Type: text/html, Size: 5679 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-31 21:33 ` Matt Corallo
@ 2014-01-01 10:02 ` Jeremy Spilman
2014-01-01 11:37 ` Wladimir
0 siblings, 1 reply; 56+ messages in thread
From: Jeremy Spilman @ 2014-01-01 10:02 UTC (permalink / raw)
To: Gregory Maxwell, Mike Hearn, Matt Corallo; +Cc: Bitcoin Dev
So I looked into gitian, the first thing I noticed was the hashes that
people were signing, for example:
https://github.com/bitcoin/gitian.sigs/blob/master/0.8.6-win32/gavinandresen/bitcoin-build.assert
don't match the hash of the file 'bitcoin-0.8.6-win32-setup.exe' actually
hosted by sourceforce. That was a bit alarming at first, but I talked to
BlueMatt and maaku on IRC and the difference is due to Gavin Authenticode
signing the executable for windows.
BlueMatt asked if someone could implement in gitian-downloader a way to
strip off the signature so that we could get back to the raw binary with a
hash that matches what everyone is producing from gitian. I found:
http://blog.didierstevens.com/programs/disitool/
which is a Python script which can strip the signature nicely, but the
hashes still don't match.
I couldn't find a gitian build of 0.8.6 so I built my own, and after
verifying the hash for v0.8.6 was '49547ff9...' as expected I looked at
the hex diff between that and the sig-stripped .exe from sourceforge, and
the only two differences are:
- At offset D8 the stripped file has '5D E2 B2' versus 'F9 F4 00' in the
gitian build
- The sig-stripped file has an extra byte '00' at the end
I started to look at the file spec for windows PE files and quickly
thought better of it. Maybe someone better informed can chime in on what
those three bytes at offset D8 specify.
I'm not sure if we want to patch the signature onto the gitian build, or
strip the signature off of the Gavin-signed build, but something of the
sort is necessary if you want get gitian-downloader to match the official
distro (for Windows at least).
In any case, I think wallet users want to know when an upgrade is
available, and ability to click an 'update' button get a binary they can
trust. It's not a problem unique to bitcoind, deterministic builds are
awesome, but I don't think fully solve it.
Thanks,
Jeremy
On Tue, 31 Dec 2013 13:33:54 -0800, Matt Corallo
<bitcoin-list@bluematt•me> wrote:
> We already have a wonderful system for secure updating -
> gitian-downloader. We just neither use it >not bother making actual
> gitian releases so anyone can use it to verify signatures of downloads.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2014-01-01 10:02 ` Jeremy Spilman
@ 2014-01-01 11:37 ` Wladimir
0 siblings, 0 replies; 56+ messages in thread
From: Wladimir @ 2014-01-01 11:37 UTC (permalink / raw)
To: Jeremy Spilman; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 589 bytes --]
>
> In any case, I think wallet users want to know when an upgrade is
> available, and ability to click an 'update' button get a binary they can
> trust. It's not a problem unique to bitcoind, deterministic builds are
> awesome, but I don't think fully solve it.
>
Deterministic builds are one part of the equation. Matt Corallo actually
did implement auto-updating using gitian updater:
https://github.com/bitcoin/bitcoin/pull/1453
It ran into lots of bike shedding and was eventually abandoned, but there
is no question whether it is possible with the current build process.
Wladimir
[-- Attachment #2: Type: text/html, Size: 1034 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-31 21:25 ` Jeremy Spilman
2013-12-31 21:33 ` Matt Corallo
@ 2014-01-01 15:10 ` Mike Hearn
1 sibling, 0 replies; 56+ messages in thread
From: Mike Hearn @ 2014-01-01 15:10 UTC (permalink / raw)
To: Jeremy Spilman; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 4033 bytes --]
That seems overly complicated, there's no need for the Bitcoin protocol to
be involved. Deterministic builds with threshold signed updates are a
problem the entire crypto community is now interested in solving - any
solution should be generic.
Really all you need is an update engine that allows a CHECKMULTISIG type
approach. When the update engine is not under our control, i.e. on Android,
Shoup style RSA threshold signatures can potentially work (though I must
admit, I have never found time to play with the implementation I have for
that algorithm).
On Tue, Dec 31, 2013 at 9:25 PM, Jeremy Spilman <jeremy@taplink•co> wrote:
> I didn't know about the dedicated server meltdown, it wasn't any of my
> infra. Anyway, my previous offer still stands.
>
> One less 'security theater' approach would be if we could provide
> forward-validation of updates using the blockchain. It's always going to be
> up to the user the first time they install the wallet to verify the
> provenance of the binaries/source. From that point forward, we could make
> it easier if the wallet could detect updates and prove they were valid.
>
> This could be as simple as hard-coding a public key into the client and
> checking a signature on the new binaries. But it could also be more
> interesting...
>
> For example, a well known address on the blockchain corresponds to
> multi-sig with keys controlled by developers (or whatever key policy the
> release team wants to impose). A spend from that address announces a new
> release, and includes the expected hash of the file.
>
> You would probably need some way to handle the different release targets.
> A more rigorous approach could identify all the various releases in terms
> of a BIP32 xpubkey whose branches would correspond to the different release
> trains and platform builds. Spends from a node announce the release and the
> expected hash.
>
> This provides zero benefit if the wallet software is already compromised,
> but I think this would allow trusted automatic update notification, and a
> trusted way to deliver the expected hashes. It also might resolve some of
> the consternation around when a release is truly "released", if that's
> really a problem.
>
> I'm not sure how far along the slope you would want to go; 1) announcing
> updates in the UI, 2) providing a button the user could click to verify a
> binary matches its expected hash, 3) click to download and verify the
> upgrade matches the expected hash, 4) click to upgrade
>
> Formalizing the release process around a set of privkeys (or split shares
> of keys) may raise its own set of questions.
>
> For the download itself, I've heard the advocates of announcing
> availability on the blockchain leading to a BitTorrent magnet link, but I
> also understand objections to adding an entire BitTorrent stack into a
> wallet.
>
> On Tue, 31 Dec 2013 06:23:55 -0800, Mike Hearn <mike@plan99•net> wrote:
>
> The site was actually moved onto a dedicated server temporarily and it
>> melted down under the load. I wouldn't call that no progress.
>>
>
> Oh, it did? When was that? I must have missed this excitement :)
>
> Any idea how much load it had?
>
> Perhaps I wasn't clear on the point I was making Drak's threat model
>> is not improved in the slightest by SSL. It would be improved by
>> increasing the use of signature checking, e.g. by making it easier.
>>
>
> Well, that depends. If you watch Applebaums talk he is pushing TLS pretty
> hard, and saying that based on the access to the source docs some of their
> MITM attacks can't beat TLS. It appears that they have the capability to do
> bulk MITM and rewrite of downloads as Drak says but *not* when TLS is
> present, that would force more targeted attacks. So to me that implies that
> TLS does raise the bar and is worth doing.
>
> However if we can't find a server that won't melt under the load, then
> that'd be an issue. We could consider hosting downloads on AppEngine or
> something else that can handle both high load and TLS.
>
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 5246 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-31 14:23 ` Mike Hearn
2013-12-31 21:25 ` Jeremy Spilman
@ 2014-01-01 22:15 ` Mike Hearn
1 sibling, 0 replies; 56+ messages in thread
From: Mike Hearn @ 2014-01-01 22:15 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 768 bytes --]
>
> Oh, it did? When was that? I must have missed this excitement :)
>>
>
I would be very interested to learn more about this. It seems the steady
state load on the site is not very high:
https://github.com/bitcoin/bitcoin.org/pull/287
(Saivann ran Google Analytics on the site for a little while to get traffic
figures). Peak of 10 visitors per second, assume a 10x blowup on resources,
that's only ~100 reqs/sec steady state, that shouldn't strain any kind of
reasonable server. So perhaps the specs of the dedicated server were not
what you might imagine.
Perhaps we should move the site over to Jeremy's hosting? It shouldn't be
very expensive to serve outside of major press cycles. Once that is done,
perhaps we can find/blag some SSL-protected file hosting.
[-- Attachment #2: Type: text/html, Size: 1534 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-31 13:59 ` Mike Hearn
2013-12-31 14:18 ` Gregory Maxwell
@ 2014-01-02 19:49 ` Jorge Timón
1 sibling, 0 replies; 56+ messages in thread
From: Jorge Timón @ 2014-01-02 19:49 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
On 12/31/13, Mike Hearn <mike@plan99•net> wrote:
> remember suggesting that we whack Google Analytics or
> some other statistics package on when the new website design was done and
> that was rejected for similar reasons ("organisations are bad").
Analytics software would be useful. I suggest using Piwik or another
free software alternative instead of Google's package.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2013-12-31 13:48 ` Gregory Maxwell
2013-12-31 13:59 ` Mike Hearn
2013-12-31 14:05 ` Benjamin Cordes
@ 2014-01-03 5:45 ` Troy Benjegerdes
2014-01-03 9:59 ` Drak
2 siblings, 1 reply; 56+ messages in thread
From: Troy Benjegerdes @ 2014-01-03 5:45 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
On Tue, Dec 31, 2013 at 05:48:06AM -0800, Gregory Maxwell wrote:
> On Tue, Dec 31, 2013 at 5:39 AM, Drak <drak@zikula•org> wrote:
> > The NSA has the ability, right now to change every download of bitcoin-qt,
> > on the fly and the only cure is encryption.
No, the only cure is the check the hashes. We should know something
about hashes here. TLS is a big pile of 'too big to audit'. Spend
a couple of satoshis and put the hash of the source tar.gz and the
binaries in the blockchain. Problem solved.
<snipped>
> The downloads are protected by something far stronger than SSL
> already, which might even have a chance against the NSA. Actual
> signatures of the downloads with offline keys.
>
> I'm all pro-SSL and all that, but you are— piece by piece— really
> convincing me that it produces an entirely false sense of security
> which is entirely unjustified.
I used to think encryption was important, and this exchange convinced
me that kerberized telnet with no encryption but with integrity
checking would be far more secure than 'secure' shell.
Also, there's some organization that's inserting malicious memes
that try to get me to buy shit below my signature. How about we
move the mailing list? I've run mailman servers before, and there's
also http://savannah.gnu.org/maintenance/WhyChooseSavannah/
-- Troy (da hozer)
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2014-01-03 5:45 ` Troy Benjegerdes
@ 2014-01-03 9:59 ` Drak
2014-01-03 11:22 ` Tier Nolan
2014-01-03 17:38 ` Troy Benjegerdes
0 siblings, 2 replies; 56+ messages in thread
From: Drak @ 2014-01-03 9:59 UTC (permalink / raw)
To: Troy Benjegerdes; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]
On 3 January 2014 05:45, Troy Benjegerdes <hozer@hozed•org> wrote:
> On Tue, Dec 31, 2013 at 05:48:06AM -0800, Gregory Maxwell wrote:
> > On Tue, Dec 31, 2013 at 5:39 AM, Drak <drak@zikula•org> wrote:
> > > The NSA has the ability, right now to change every download of
> bitcoin-qt,
> > > on the fly and the only cure is encryption.
>
> No, the only cure is the check the hashes. We should know something
> about hashes here. TLS is a big pile of 'too big to audit'. Spend
> a couple of satoshis and put the hash of the source tar.gz and the
> binaries in the blockchain. Problem solved.
Which is why, as pointed out several times at 30c3 by several renowned
figures, why cryptography has remained squarely outside of mainstream use.
It needs to just work and until you can trust the connection and what the
end point sends you, automatically, it's a big fail and the attack vectors
are many.
<sarcasm>I can just see my mother or grandma manually checking the hash of
a download... </sarcasm>
Drak
[-- Attachment #2: Type: text/html, Size: 1501 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2014-01-03 9:59 ` Drak
@ 2014-01-03 11:22 ` Tier Nolan
2014-01-03 13:09 ` Adam Back
2014-01-03 17:38 ` Troy Benjegerdes
1 sibling, 1 reply; 56+ messages in thread
From: Tier Nolan @ 2014-01-03 11:22 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]
On Fri, Jan 3, 2014 at 9:59 AM, Drak <drak@zikula•org> wrote:
> Which is why, as pointed out several times at 30c3 by several renowned
> figures, why cryptography has remained squarely outside of mainstream use.
> It needs to just work and until you can trust the connection and what the
> end point sends you, automatically, it's a big fail and the attack vectors
> are many.
>
> <sarcasm>I can just see my mother or grandma manually checking the hash of
> a download... </sarcasm>
>
Maybe a simple compromise would be to add a secure downloader to the
bitcoin client.
The download link could point to a meta-data file that has info on the
download.
file_url=
hash_url=
sig_url=
message=This is version x.y.z of the bitcoin client
It still suffers from the root CA problem though. The bitcoin client would
accept Gavin's signature or a "core team" signature.
At least it would provide forward security.
It could also be used to download files for different projects, with
explicit warnings that you are adding a new trusted key.
When you try to download, you would be given a window
Project: Some Alternative Wallet
Signed by: P. Lead
Message:
Confirm download Yes No
However, even if you do that, each trusted key is only linked to a
particular project.
It would say if the project and/or leader is unknown.
[-- Attachment #2: Type: text/html, Size: 2358 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2014-01-03 11:22 ` Tier Nolan
@ 2014-01-03 13:09 ` Adam Back
0 siblings, 0 replies; 56+ messages in thread
From: Adam Back @ 2014-01-03 13:09 UTC (permalink / raw)
To: Tier Nolan; +Cc: Bitcoin Dev
You know if you want to make some form of investment, you might like make an
attempt to look them up on the internet, check the phone number in a phone
book or directory enquiries, look for references and reviews?
So it is with the hash of the binary you are about to trust with your
investment funds. I dont think its such a difficult question. Ask your
more technical friends to confirm this hash is correct.
Its interesting that hashes are more trustworthy than signatures, since all
the NSLs and backdoors, its hard to trust a signature.
I have the same problem with linux distros that want to install hundreds of
components downloaded over the internet, based on signatures. I would far
rather a merkle hash of the distribution at that point in time, which
authenticates directly any of the optional downloadable components.
(Or better yet a distro that like comes on a CD and doesnt download
anything... Amazing how most CD and even DVD iso images immediately
download stupid things like fonts??? What were they thinking? I downloaded
fedora > 4GB of stuff and they need to download a font just to get past step
2 of the installer? Thats a sensless, retrograde, selective backdoor
opportunity.)
Adam
On Fri, Jan 03, 2014 at 11:22:35AM +0000, Tier Nolan wrote:
> On Fri, Jan 3, 2014 at 9:59 AM, Drak <[1]drak@zikula•org> wrote:
>
> Which is why, as pointed out several times at 30c3 by several renowned
> figures, why cryptography has remained squarely outside of mainstream
> use. It needs to just work and until you can trust the connection and
> what the end point sends you, automatically, it's a big fail and the
> attack vectors are many.
> <sarcasm>I can just see my mother or grandma manually checking the hash
> of a download... </sarcasm>
>
> Maybe a simple compromise would be to add a secure downloader to the
> bitcoin client.
> The download link could point to a meta-data file that has info on the
> download.
> file_url=
> hash_url=
> sig_url=
> message=This is version x.y.z of the bitcoin client
> It still suffers from the root CA problem though. The bitcoin client
> would accept Gavin's signature or a "core team" signature.
> At least it would provide forward security.
> It could also be used to download files for different projects, with
> explicit warnings that you are adding a new trusted key.
> When you try to download, you would be given a window
> Project: Some Alternative Wallet
> Signed by: P. Lead
> Message:
> Confirm download Yes No
> However, even if you do that, each trusted key is only linked to a
> particular project.
> It would say if the project and/or leader is unknown.
>
>References
>
> 1. mailto:drak@zikula•org
>------------------------------------------------------------------------------
>Rapidly troubleshoot problems before they affect your business. Most IT
>organizations don't have a clear picture of how application performance
>affects their revenue. With AppDynamics, you get 100% visibility into your
>Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
>http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists•sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2014-01-03 9:59 ` Drak
2014-01-03 11:22 ` Tier Nolan
@ 2014-01-03 17:38 ` Troy Benjegerdes
2014-01-03 18:21 ` Jorge Timón
1 sibling, 1 reply; 56+ messages in thread
From: Troy Benjegerdes @ 2014-01-03 17:38 UTC (permalink / raw)
To: Drak; +Cc: Bitcoin Dev
On Fri, Jan 03, 2014 at 09:59:15AM +0000, Drak wrote:
> On 3 January 2014 05:45, Troy Benjegerdes <hozer@hozed•org> wrote:
>
> > On Tue, Dec 31, 2013 at 05:48:06AM -0800, Gregory Maxwell wrote:
> > > On Tue, Dec 31, 2013 at 5:39 AM, Drak <drak@zikula•org> wrote:
> > > > The NSA has the ability, right now to change every download of
> > bitcoin-qt,
> > > > on the fly and the only cure is encryption.
> >
> > No, the only cure is the check the hashes. We should know something
> > about hashes here. TLS is a big pile of 'too big to audit'. Spend
> > a couple of satoshis and put the hash of the source tar.gz and the
> > binaries in the blockchain. Problem solved.
>
>
> Which is why, as pointed out several times at 30c3 by several renowned
> figures, why cryptography has remained squarely outside of mainstream use.
> It needs to just work and until you can trust the connection and what the
> end point sends you, automatically, it's a big fail and the attack vectors
> are many.
>
> <sarcasm>I can just see my mother or grandma manually checking the hash of
> a download... </sarcasm>
'make' should check the hash. The binary should check it's own hash. The
operating system should check the hash.
How about if I sell your Grandma an android table loaded only with free
software, and use the existing infrastructure android provides to only
allow software to be installed that can be integrity-verified from a
public key that can be downloaded from the blockchain?
Would you pay $50 (or 2 litecoin) more for at tablet with free software
that protects you and your grandma's interests, rather than selling them
to google/apple/microsoft?
I'm working on eventually being able to build hardware for which the
entire design specifications, from case to cpu core verilog, all they way
up to the pre-installed cryptographic currency wallet(s) are all signed
and released as part of the Debian archive.
But I need people like you to explain to your Grandma why this hardware
costs more than hardware that monetizes eyeballs and sells your private
information to the highest bidder.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2014-01-03 17:38 ` Troy Benjegerdes
@ 2014-01-03 18:21 ` Jorge Timón
2014-01-04 1:43 ` Troy Benjegerdes
0 siblings, 1 reply; 56+ messages in thread
From: Jorge Timón @ 2014-01-03 18:21 UTC (permalink / raw)
To: Troy Benjegerdes; +Cc: Bitcoin Dev
On 1/3/14, Troy Benjegerdes <hozer@hozed•org> wrote:
> 'make' should check the hash.
An attacker could replace that part of the makefile.
Anyway, I think this is more oriented for compiled binaries, not for
people downloading the sources. I assume most of that people just use
git.
> The binary should check it's own hash.
I'm afraid this is not possible.
> The operating system should check the hash.
There's package management systems like apt-secure that do exactly this.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
2014-01-03 18:21 ` Jorge Timón
@ 2014-01-04 1:43 ` Troy Benjegerdes
0 siblings, 0 replies; 56+ messages in thread
From: Troy Benjegerdes @ 2014-01-04 1:43 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin Dev
On Fri, Jan 03, 2014 at 07:21:17PM +0100, Jorge Timón wrote:
> On 1/3/14, Troy Benjegerdes <hozer@hozed•org> wrote:
> > 'make' should check the hash.
>
> An attacker could replace that part of the makefile.
> Anyway, I think this is more oriented for compiled binaries, not for
> people downloading the sources. I assume most of that people just use
> git.
>
> > The binary should check it's own hash.
>
> I'm afraid this is not possible.
>
> > The operating system should check the hash.
>
> There's package management systems like apt-secure that do exactly this.
Yes. Promoting operating systems (and signed .deb packages) is a far better
thing to do than worrying about TLS on the bitcoin.org server.
^ permalink raw reply [flat|nested] 56+ messages in thread
end of thread, other threads:[~2014-01-04 1:43 UTC | newest]
Thread overview: 56+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-08 1:17 [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts? Saïvann Carignan
2013-12-08 3:38 ` Odinn Cyberguerrilla
2013-12-08 9:03 ` Saïvann Carignan
2013-12-08 12:37 ` Luke-Jr
2013-12-08 19:16 ` Drak
2013-12-08 19:25 ` Gregory Maxwell
2013-12-08 20:28 ` Mike Hearn
2013-12-08 20:40 ` Gregory Maxwell
2013-12-08 20:51 ` Drak
2013-12-08 21:01 ` Luke-Jr
2013-12-08 21:11 ` Drak
2013-12-08 23:51 ` theymos
2013-12-09 0:06 ` Taylor Gerring
2013-12-09 6:29 ` Jeremy Spilman
2013-12-09 10:54 ` Roy Badami
2013-12-10 9:18 ` Odinn Cyberguerrilla
2013-12-08 21:09 ` Gregory Maxwell
2013-12-08 21:16 ` Saïvann Carignan
2013-12-08 21:58 ` Roy Badami
2013-12-08 23:03 ` Mike Hearn
2013-12-09 5:32 ` Jeff Garzik
2013-12-08 22:44 ` Gavin Andresen
2013-12-08 23:48 ` Saïvann Carignan
2013-12-08 23:18 ` Luke-Jr
2013-12-08 23:29 ` Patrick
2013-12-08 21:46 ` Mark Friedenbach
2013-12-08 20:40 ` Drak
2013-12-08 20:50 ` Gregory Maxwell
2013-12-08 21:07 ` Drak
2013-12-08 21:14 ` Gregory Maxwell
2013-12-08 22:27 ` Robert McKay
2013-12-12 20:51 ` Adam Back
2013-12-31 13:39 ` Drak
2013-12-31 13:48 ` Gregory Maxwell
2013-12-31 13:59 ` Mike Hearn
2013-12-31 14:18 ` Gregory Maxwell
2013-12-31 14:23 ` Mike Hearn
2013-12-31 21:25 ` Jeremy Spilman
2013-12-31 21:33 ` Matt Corallo
2014-01-01 10:02 ` Jeremy Spilman
2014-01-01 11:37 ` Wladimir
2014-01-01 15:10 ` Mike Hearn
2014-01-01 22:15 ` Mike Hearn
2014-01-02 19:49 ` Jorge Timón
2013-12-31 14:05 ` Benjamin Cordes
2014-01-03 5:45 ` Troy Benjegerdes
2014-01-03 9:59 ` Drak
2014-01-03 11:22 ` Tier Nolan
2014-01-03 13:09 ` Adam Back
2014-01-03 17:38 ` Troy Benjegerdes
2014-01-03 18:21 ` Jorge Timón
2014-01-04 1:43 ` Troy Benjegerdes
2013-12-08 10:00 ` Drak
2013-12-08 12:39 ` Luke-Jr
2013-12-08 16:51 ` Gregory Maxwell
2013-12-08 16:08 ` Wladimir
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox